StatusBeacon for Jira Service Management

StatusBeacon for Jira Service Management

StatusBeacon puts a service status page and incident banners on your Jira Service Management customer portal. Agents set the status of each component and post incidents from a page inside the service project. Customers see it at the top of every portal page, at the bottom as a full status page, and on their own requests.

Atlassian's built-in status pages are only on the Service Collection Enterprise plan. This app gives Standard and Premium sites the part customers look at most, which is "is it down, and what are you doing about it".

It runs on Atlassian Forge with no egress and no remote servers. Nothing leaves your Atlassian site.

What customers see

There are three places on the portal.

• The portal header shows one banner per open incident or maintenance. Major and critical incidents are red, minor ones are yellow, and maintenance is blue. Each banner has the title, impact, current state, affected components and the latest update with its time. When nothing is open but a component isn't operational, the header names those components instead. An optional green "all services are running normally" line can be switched on.
• The portal footer is the status page. It shows the overall status, every open item with all its updates, and each component with its status. Below that it lists up to the 20 most recent incidents and maintenance closed in the last 90 days, with how long each one lasted. An incident counts from when it was posted. Maintenance counts from its first In progress update. If nobody posted one, it counts from the start of its window and stops at the window's end, so marking it Completed late doesn't make it look longer.
• Each customer request gets a "Service status" panel with the overall status and any open incidents. It stays empty until you've added a component or posted something, so it never says "all fine" with nothing behind it.

Scheduled maintenance shows up on the portal 7 days before its start time. Until then only agents see it. If its window ends and nobody moved it to In progress or Completed, customers stop seeing it, and the agent page flags it so someone can move it on or change the window with Edit.

All times are shown in UTC.

What agents do

Open the service project and pick Status page in the sidebar. The app asks Jira to show that entry only in service projects. If it's opened in another project anyway, it says it can't find a service desk for that project.

Agents (people with the Service Desk Agent permission in that project) can do the following.

• Set a component's status to Operational, Degraded performance, Partial outage, Major outage or Under maintenance.
• Post an incident with a title, an impact (minor, major or critical), a state, the affected components and a first update. You can set the affected components to a status in the same step.
• Post updates as the incident moves through Investigating, Identified, Monitoring and Resolved. An incident takes up to 20 updates, and the one that resolves it is always accepted on top of those. When you resolve it, the app can set its components back to Operational. It leaves a component alone if another open incident still lists it.
• Post maintenance with a start and end time (UTC, written as 2026-11-20 22:00), then move it to In progress and Completed. A Scheduled window has to end in the future, since customers would never see one that's already over. Maintenance can only go back to Scheduled when it has a window that hasn't ended.
• Edit an open incident's title, impact or components, or an open maintenance's title, components or start and end time. Delete one that was posted by mistake.

Project admins can also add, rename, reorder and delete components, and switch the header all-clear line, the footer history and the request panel on or off.

Everything you type on this page is shown to customers. Don't put internal notes in it.

Which portal it shows on

Portal modules only get the customer portal's id from Jira, and that id isn't always the same as the service desk id. Atlassian's own help says they usually match but can differ, for example on older or migrated projects. So StatusBeacon reads the portal id from the project's request types when an agent opens the Status page, and it stores the status page under that portal id.

The Status page names the portal path it found, such as /servicedesk/customer/portal/3. Open that portal once after setup to check the status page shows up there. If the project has no request types, or they point at different portals, the app can't tell which portal is the right one. Then it refuses to save anything and asks you to add a request type, so a status page can't land on another team's portal.

History

Closed incidents and maintenance stay on the status page for 90 days after they close, and the footer shows the 20 most recent of them. The agent page lists every one from those 90 days. Component status changes are logged for 90 days too, and the last 50 show on the agent page. After 90 days an item no longer shows anywhere. It's deleted from storage the next time an agent saves a change. Opening the Status page only reads, so it never changes anything.

Limits

If a page gets close to Forge's storage size limit, the oldest closed incidents are removed first. If open incidents alone are too big, the app refuses the change and says so.

If someone else saved a change after you loaded the Status page, your save is refused with a message and the page shows the latest version. Then you can check it and try again. Forge storage has no locking here, so two saves that land at almost the same moment can both go through, and the later one wins.

If an agent can see more than 1,000 service projects and this one isn't among the first 1,000, the Status page says so instead of guessing.

Permissions and data

The app asks for three scopes.

• read:jira-work to call GET /rest/api/3/mypermissions as the agent, which tells it whether that person is an agent or a project admin in the project.
• read:servicedesk-request to call GET /rest/servicedeskapi/servicedesk and GET /rest/servicedeskapi/servicedesk/{id}/requesttype as the agent. The first finds the service desk that belongs to the project. The second gives the id of its customer portal.
• storage:app to keep one status record per customer portal in Forge storage, a smaller copy of it for portal views, and a cached link from project to service desk and portal.

Portal views make no Jira calls at all. They read the small saved copy for the portal being viewed, which leaves out the change log and older history.

The app stores the component names, statuses, incident text and times that agents enter. It doesn't store account IDs, names or email addresses. See PRIVACY.md.

Install and set up

1. Install StatusBeacon from the Atlassian Marketplace.
2. Open a service project, pick Status page in the sidebar, and add your components (project admin).
3. Visit the customer portal. The footer shows your components. The header stays empty until something is wrong, unless you switch on the all-clear line.

Support

Use the support link on the app's Marketplace listing.

Support Zovo

Zovo builds and maintains this app. If it saves you time, you can support the work on GitHub Sponsors. Sponsorship is optional, and the tool works the same without it.

Zovo is made by theluckystrike on GitHub.

More tools by Zovo

• Portal SLA Clocks. Shows customers their SLA times in the Jira Service Management portal.
• Dashboard Notes. Puts a formatted note on any Jira dashboard.
• Description Diff. Shows what changed in a Jira issue description, word by word.
• Epic Totals. Adds up story points, estimates and time logged for the children of a Jira epic.