Super SLA

Why

Jira Service Management shows SLA cycles one issue at a time. The met-vs-breached report shows the wrong breach dates on old issues. When an admin edits a calendar or a goal, Jira recalculates the open cycles it affects. The audit log records the edit itself and nothing about the cycles it moved. 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, the personal data reporting scope, and app data scopes for its own issue fields and JQL functions. It writes nothing to your Jira configuration, and on issues it writes only its own SLA fields. It makes no network calls outside Atlassian.

Open the app

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

First read

On install the app reads every issue in every service project and stores its cycles. Ten thousand issues take from a few minutes to about twenty, depending on how many cycles and changes each issue has. 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, or by any JQL your Jira accepts. 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.

On the issue

The app keeps four read-only fields on every service project issue: SLA state (Met, Breached, Running or Paused), SLA breached at, SLA elapsed in minutes, and SLA next due. They follow one SLA, chosen on the Capture tab; Time to resolution by default. Add them as columns in the issue navigator, search them with JQL such as "SLA state" = Breached AND "SLA breached at" >= -7d, include them in any export, or use them in Automation conditions. Values are written by the hourly read and the daily re-read, so a running cycle's elapsed time is as of the issue's last change or the last daily re-read. Writing them does not touch the issue's history or its updated time.

A fifth field, SLA at risk, names every SLA on the issue that will breach within a threshold you set on the Capture tab, an hour by default. It is checked every hour from the app's store, so an issue nobody has touched is still flagged as its deadline nears. To act on it, create an Automation rule: when SLA at risk changes and is not empty, notify the assignee, reassign, or post to a channel. The app itself sends nothing.

On any issue

An SLAs panel on every issue, in any Jira project, shows the issue's own SLA cycles and those of every issue linked to it. A developer working a Jira Software bug sees the service request it is blocking and how long is left. Viewers see only the service projects they can browse.

On the customer portal

My SLAs, in the portal's user menu, lists a customer's open requests with their SLA states, soonest deadline first. Each request on the portal shows a Service level agreements panel: every SLA cycle on that request, whether it is running, paused, met or breached, the time used or left against the goal, and when it is due or was finished. Customers see the requests Jira lets them see: their own and any shared with them. The panel shows no assignee names; approver names only if you turn them on. Under Customer portal on the app's Capture tab you choose which SLAs customers see, give each a public name such as Response time, and set the share of the goal at which a running cycle reads as Due soon. Running times are as of the request's last read, within the hour if it changed and from the daily re-read otherwise, and the panel says when that was.

Approvals

Every approval decision on a service request that the capture sees, recorded when it first sees it: the step, the approver, their decision and the step's outcome, for up to 50 approval steps per request. Decisions stay in the ledger after the request changes. The Approvals tab lists them with project, decision and date filters and CSV export. On the customer portal, the request panel shows each approval step as last read, with its decisions, under the service levels; a Capture tab setting, off by default, decides whether customers see approver names or only each step's outcome and count. The ledger lists decisions people made; a step closed without one, such as by an automation rule, shows its outcome on the portal panel and adds no ledger row. The approval ledger can be switched off on the Capture tab.

Reports

Eight reports over the store, each filtered by project, SLA, priority, request type and customer organisation, and each exportable as CSV. The period filter applies to the reports over time; repeated cycles and goals in use cover all stored cycles, and imminent breaches look at the coming week:

• Met against breached by month, with the percentage met.
• Breaches by the week they happened, which is not the week the ticket closed.
• Breaches by the person who held the issue when it breached.
• Met against breached by current assignee.
• Imminent breaches by owner, grouped by time left.
• Working time to completion by week, with the average, median, 90th percentile and maximum taken from Jira's own elapsed time, so your calendars are honoured.
• Issues whose SLA ran more than once, from a reopen or a start condition firing again, with the cycle and breach counts.
• The goals actually in use, by SLA, request type and priority.

Reviewing breaches

On the Breach ledger, any breach can be reviewed: a reason such as customer delay, third party or misconfiguration, a note, and whether the breach is excused. The review records who made it and when. Excused breaches leave the adjusted figures, which reports, the met-vs-breached gadget and the compliance pack show beside the raw ones, and the pack lists each excused breach with its reason. That is the management review of breaches that ISO 20000 asks for, and the documented exception a SOC 2 reviewer asks for.

Targets

Set a percent-met target by default, per project, or per customer organisation. Reports, the gadget and the compliance pack show target against actual, after excused breaches, and say whether it was met. A pack can be built for one organisation, for the monthly review with that customer. A request shared with several organisations is counted in none of their single-organisation views, packs or targets.

Switching features off

Every feature beyond capture has a switch on the Capture tab: issue fields, the at-risk field, JQL functions, the Rovo agent, the portal panel and page, the issue panel, gadgets, reports, the monthly pack, reviews, targets and the approval ledger. Off means the feature answers nothing and writes nothing new. Switching the at-risk field off clears the flags it set, and data already stored is kept. Capture keeps running either way.

Compliance packs

On the first of each month the app builds a PDF for the month before: completed cycles met against breached by project and SLA, the recalculations seen, and every breach by the time it happened with the goal, the time used and the assignee at breach. Build one for any month and project from the Reports tab. Packs are kept in the app's store. Building a pack again for the same month, project and organisation replaces the earlier file, and the weekly privacy run rebuilds packs that name a closed or renamed account. A pack lists up to 2,000 breaches. The Breach ledger shows at most 2,000 matching rows and does not page, so narrow a longer list by date, project or SLA before exporting it.

In JQL

Four functions search the store from any filter, board, subscription or Automation rule: issue in slaBreached("Time to resolution", "-7d") for cycles that breached in a period, issue in slaAtRisk("2h") for running cycles due within a time, issue in slaState("Breached") for the latest cycle's state, and issue in slaCycles(2) for issues whose SLA ran more than once. The SLA argument is optional and takes the SLA's name; times are like -7d, 24h or a date. A result lists at most 1,000 issues, newest first, and is refreshed every hour.

Ask Rovo

On sites with Rovo, the Super SLA agent answers questions from the store: how your SLAs did over a period, which cycles breached and who held the issue at that moment, what is about to breach in the next few hours, and the full SLA history of one issue including earlier cycles from reopens. It answers only for the service projects you can browse, and every answer says when the data was last read.

Gadgets

Breaches ahead counts running cycles due to breach each day over the coming week, against the recent weekly rate. 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, one SLA, one priority and one request type from its settings.

What the app does not do

• It does not define, pause, or recalculate SLAs. Jira does that; the app records the result.
• A breach by passage of time on an untouched issue is seen within the hour, and a configuration edit within the day. Neither is instant.
• History starts when the app is installed. The first read copies every cycle Jira still holds; anything Jira had already discarded is gone.

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 storage in your site's region. After uninstall Atlassian keeps it for 28 days, then deletes it. To recover it, ask us within 21 days of uninstalling; reinstalling alone does not bring it back. Details in the privacy policy.