Altoria

Super SLA

SLA history for Jira Service Management. Every native SLA cycle is copied into the app's own store as it happens and kept: a breach ledger with the assignee at breach, a record of what recalculations changed, a list of issues with no SLA at all, CSV export, and two dashboard gadgets. No SLA setup of its own.

Why

Jira Service Management shows an SLA while it runs and forgets most of it afterwards. The met-vs-breached report shows the wrong breach dates on old issues. A reopened issue hides its earlier cycles. When an admin edits a calendar or a goal, every open cycle is recalculated and nothing is written to the audit log. Super SLA reads the SLAs you already have and keeps what Jira drops.

Install

Install from the Atlassian Marketplace as a Jira site administrator. The app asks for read scopes, app storage, and the personal data reporting scope. It writes nothing to your Jira configuration or issues and makes no network calls outside Atlassian.

Open the app

In Jira, open Settings, then Apps, then Super SLA in the left sidebar. Only site administrators can see it. The gadgets are on the Add gadget list of any dashboard, under the names Super SLA: met vs breached per week and Super SLA: open cycles by time to breach.

First read

On install the app reads every issue in every service project and stores its cycles, about two minutes per ten thousand issues. After that it reads issues updated in the last hour, checks every hour for cycles whose breach time has passed, and re-reads everything once a day to catch recalculations. The Capture tab shows when each of these last ran and what it found.

Breach ledger

One row per breached cycle: the issue, the SLA, which cycle of that SLA it is, when it breached, who held the issue at that moment, the goal, the elapsed time, how far over goal it ran, whether the issue is still open, and who holds it now. Filter by project, SLA and breach date. Export CSV downloads the filtered rows.

A cycle whose breach time has passed but which Jira has not yet reported as breached is listed too, labelled "Past breach time, not re-read yet". The hourly check re-reads it and the label goes away.

Recalculations

Each row is one recalculation the capture saw: the cycles of one SLA in one project that moved the same way within half an hour. A cycle completing is not listed. Twenty or more issues moving together is labelled as a goal or calendar edit; fewer is labelled as a re-evaluation, which Jira does on its own when an issue's match against the SLA goals changes. Open the row's example to see the before and after.

The app cannot read SLA configuration, since Atlassian exposes no API for it. It infers an edit from the cycles and says so.

Coverage

Service project issues with no SLA cycle at the last read. An issue with no request type has no SLA at all; an issue whose SLA never started has the field but no cycle. Neither appears in any SLA report. Filter by project and by the kind of gap.

Gadgets

Met vs breached per week counts completed cycles by the week they stopped. Open cycles by time to breach groups running cycles by time left: under an hour, one to four hours, four to twenty-four hours, one to seven days, over seven days, and past breach time. Each gadget has a table view under the chart and can be limited to one project and one SLA from its settings.

What the app does not do

Large sites

An hourly read has a fourteen-minute budget. If a very large site exceeds it, the Capture tab marks the run incomplete and the next hour continues from the same point. Tell us your issue count through support and we will look at it.

Data and privacy

Everything the app stores lives in Atlassian Forge SQL in your site's region. Uninstalling the app deletes it. Details in the privacy policy.