Outage & Maintenance Banners: user guide

Show one notice on your Jira Service Management customer portal and in Confluence, at the same time. Schedule maintenance, flag outages, post holiday hours, and see how many people saw each notice.

Install

  1. Install the app from the Atlassian Marketplace on your Jira site.
  2. Optional: also install it in Confluence on the same site, so the same notices show there. Notices are shared between both.
  3. Open Jira settings → Apps → Announcement banners (or Confluence settings → Apps → Announcement banners). In Jira and Confluence the app appears as Announcement banners.
    • Jira admins manage every notice, including portal notices and outages, and can let chosen Jira groups post (see "Let your team post notices").
    • Confluence admins (who aren't Jira admins) manage notices that show only in Confluence. Portal notices and outages are posted from Jira, because they reach your customers.

Create a notice

  1. Click New notice (or, the first time, one of the Get started buttons).
  2. Pick a template (Scheduled maintenance, Outage, Holiday hours, Migration notice, New feature) or start blank.
  3. Choose the notice type. The colour follows it: Maintenance (yellow), Outage (red), Resolved (green), Holiday hours (purple), Notice (blue).
  4. Write a title (up to 80 characters) and a message (up to 280). The portal shows both; Confluence shows the title only, on one line.
  5. Set when it starts and ends. Times are in your time zone; every viewer sees them in their own.
    • Start now shows it straight away.
    • No end time keeps it up until you pause or delete it.
    • Show a heads-up before it starts shows an upcoming notice with a countdown, 0–14 days ahead (3 days by default for maintenance and holiday hours).
  6. Optional: add a link, such as your status page.
  7. Choose where it shows (next section), check the Live preview, and click Publish notice (or Schedule notice if it starts later).

Choose where it shows

  • Service portal: all portals and the help center, or only the portals you pick. Then tick the portal pages: Help center, Portal home, Raise a request, View a request, My requests and approvals, Profile.
  • Confluence: all spaces, or only the spaces you pick.

If several notices match a page, viewers see one: a live notice beats an upcoming one, then the most serious type wins (Outage, then Maintenance, then Resolved, then the rest), then the newest.

Incident mode

  • Click Post outage notice, optionally say what's affected (for example "Email"), and post. Trying it out first? Choose Test first and pick a test portal or space: nobody else sees it, and Show it everywhere on the incident card widens it when you're ready.
  • Agents (or anyone allowed to post) can also start it from a major-incident request: ••• → Post outage notice picks the service from the request summary ("Email" from "Email down for everyone" or "Can't connect to the VPN"; it's left blank if the summary doesn't name one), and every other agent then sees that request as the main incident.
  • Copy for Slack, Teams or email on the incident card gives the same wording for your team channel. The app itself never sends messages, so nothing leaves your site. The notice shows at once on every portal and every Confluence space: "Email: we're investigating a problem".
  • Post updates as you learn more: pick a stage (Investigating, Cause found, Fixed, monitoring), add a short note, and promise the next update (in 15 min to 2 hours). Customers see a timestamped timeline and "Next update by 01:14" in their own time zone; Confluence shows the latest stage. If the promised time passes, the admin page reminds you to post.
  • "I'm affected too": customers can click it on the outage notice instead of raising a request. They see how many others reported it, and you see the count on the admin page.
  • A new notice shows on pages opened from about 20 seconds after you post it. Open pages refresh outage and maintenance notices every 2 minutes. Someone who dismissed a notice sees it again when there's a new update.
  • Agents see it too: while an outage is live, every request in a service project shows a "Live outage" panel with the latest update, and says whether the request came in after the outage started, so agents can link duplicates instead of triaging each one.
  • Click Mark as resolved when it's fixed, then confirm. The notice turns green ("Resolved: Email is working again") and disappears by itself after 2 hours.
  • Optional, Jira admins only: in the same step, tick Also reply to the requests raised during the outage. You see the reply and each request (only from the outage's portals, plus the main incident request) and can untick any that aren't related. Replies are posted as you, and JSM emails each customer as usual. It's off unless you tick it.
  • Agents see a suggested reply in the "Live outage" panel on each request, ready to copy.
  • People who dismissed the outage still see the Resolved notice.

Run outage mode from Jira Automation

Three actions appear in the Automation rule builder under Other apps: Post outage notice, Post outage update and Resolve outage notice. For example: "When a request with priority Highest is created → Post outage notice", and "When that request is resolved → Resolve outage notice".

  • Post outage notice: say what's affected (type "Email", or use a smart value such as {{issue.summary}}). Put {{issue.key}} in Main incident request so agents see that request as the main incident and the later steps can find this outage.
  • Post outage update: pick a stage, add an optional note, and promise the next update. It finds the outage by the request key, then by what's affected; if only one outage is live and both are empty, it uses that one.
  • Resolve outage notice: finds the outage the same way and marks it resolved. If nothing is live it does nothing, so the rule doesn't fail. Ticking Also reply to the requests raised during the outage works only when the rule's actor is a Jira admin.
  • Rules run as the rule's actor, with the same checks as the admin page: the actor must be a Jira admin or in a group allowed to post notices. Errors appear in the rule's audit log.
  • The first time you add one of these steps, Jira asks you to Connect Automation to the app. That's a one-time consent per rule.

Tickets saved

For outages and maintenance windows, the list shows how many requests came in compared with what's usual for the same hours over the previous 7 days, for example "≈24 fewer requests than usual (6 raised vs ~30 usual in 3 hours)". It's an estimate. It starts after the app has 3 days of request history. Until then you'll see how many requests came in since the notice started.

The list also shows how many views were on the Raise a request form: that's where a notice stops someone from raising a duplicate ticket.

Maintenance progress

While a maintenance window is under way, the portal notice shows a progress bar and the time left. Running over? Click +30 min in the list and customers see the new end time.

Notices on specific request forms

Under Where it shows, choose Only on these request forms and pick request types, for example "New laptops take about 3 weeks to arrive" on the laptop form. It shows on that form and on requests of that type, under any page-wide notice, so it's never hidden by maintenance or other notices.

Incident history

The admin page lists outages from the last 90 days with their duration and how many people were affected. Summary gives a plain-text account (timeline, people affected, requests) to paste into a post-incident report.

Who changed what

Each notice in the list shows its latest change, for example "Resolved by Asha Rao · 01:09", so you can see who posted, paused, extended or resolved it.

Let your team post notices

Jira admins can choose groups under Who can post notices (at the bottom of the admin page). People in those groups can create notices, run incidents and post updates from Apps → Announcement banners in Jira, without being Jira admins.

Manage notices

  • The list shows each notice's status (Live, Scheduled, Paused, Ended), where it shows, its time window, and how many people saw it and clicked its link.
  • Pause hides a notice without deleting it; Resume brings it back.
  • Delete asks you to confirm first.
  • If two admins edit the same notice at once, the second save is stopped with a message, so nobody overwrites the other's change.

What viewers see

  • Portal: a coloured message box with the title, message, time window in their own time zone, a countdown, your link and a Dismiss button.
  • Confluence: a one-line coloured strip at the top of pages and spaces, with the full time window on hover. Confluence requires page banners to be dismissible.
  • A dismissed notice stays hidden in that browser.

Counts

  • Views count once per browser per day, per notice.
  • Clicks count each click on the notice's link.
  • Counts are numbers only; the app records nothing about who viewed or clicked.

Subscription

If the app's subscription ends, notices stop showing to customers and readers, and admins see a warning on the admin page. Your notices and history are kept, and show again as soon as the subscription is active.