Ask a Jira admin at a 3,000-person company how many SLA configurations their instance runs. The honest answer is usually "I'd have to check."
That pause is the real enterprise SLA problem. Timers rarely break. Control does: dozens of projects, teams across time zones, and rules that made sense one at a time but no longer add up.
Native Jira tooling wasn't designed for this. Jira Service Management SLAs are configured project by project and only cover service projects, while enterprise commitments live everywhere. That gap is why we built SLA Time and Report for Jira: one SLA layer across your whole instance. Below are the five places where control usually slips, and how teams use the app to get it back.
1. One rule, one source of truth
The same "P1 resolved in 4 hours" rule often lives in 25 projects as 25 copies. Someone tweaks the pause status in one, and from then on your cross-project report compares numbers calculated differently.
The fix is to treat an SLA as a shared policy, not a project setting. In SLA Time and Report, one configuration can cover several projects, so a change happens once and applies everywhere. Folders and a clear naming convention, such as "EMEA – First Response – Tier 1", keep a long list readable for the next admin.
The same logic reaches beyond the service desk. Internal OLAs, engineering escalations, and vendor tasks in Jira Software get the same rules and reports as customer tickets, instead of living in a side spreadsheet.
2. Every SLA needs an owner
When anyone with admin rights can edit any SLA, a contractual target can change without the person accountable for it ever knowing. In a regulated company, that's an audit finding waiting to happen.
Clear ownership fixes it. In SLA Time and Report, access is set per SLA: the platform team owns company-wide targets, each business unit owns its service desk SLAs, and customer contracts stay with the delivery manager responsible for them. Saved report views can be shared the same way, so each stakeholder sees what matters to them.
One thing to plan for: SLA access is separate from Jira project permissions. If someone can't see an SLA, check both.
3. Time your team can trust
A global queue measured against one calendar counts Manila's night against the Toronto team. Once agents notice, they stop trusting the number, and an untrusted SLA gets ignored.
SLA Time and Report counts time against real working hours and country public holidays, so nights and days off never land on the team's record. For distributed teams, Multi-schedule SLA type adds per-assignee schedules: a ticket handed from Manila to Toronto at shift change continues on Toronto's hours. One SLA serves every region, and the breach rate reflects performance, not geography.
4. Fewer rules that do more
Gold, Silver, and Bronze customers. Critical and standard services. Internal and external requesters. Build a separate SLA for every combination and you'll soon be managing 200 of them.
One SLA can pick its target from context: priority, request type, customer tier, or any custom field.
Edge cases like reclassified tickets, reopened work, or per-item contract deadlines are handled inside the same rule. What you get is a short list of SLAs that someone can actually review in one sitting.
5. Hear about a breach while you can still prevent it
A monthly report tells you what you've already paid for. Control means getting the signal while there's still time to act.
SLA Time and Report builds that signal into the SLA itself: warnings when a set share of time is used, and automatic actions when a goal is exceeded. A practical pattern for P1 incidents:
- At 75% of the target, the team lead gets a heads-up.
- At 100%, the ticket goes to the engineer and its priority goes up.
- At the same moment, the incident channel in Slack or Microsoft Teams gets the alert.
Each step reaches only the people who can act on it, which keeps alerts from turning into noise.
6. Different answers for different people
Agents, managers, and executives ask different questions about the same SLAs. One giant dashboard answers none of them well, so SLA Time and Report gives each group its own view of the same data:
Audience | Their question | What helps |
|---|
Agents | What should I work on next? | Time left on every work item; a queue sorted by risk |
Managers | Where and why are we missing targets? | Met vs Exceeded by team, priority, or request type on their Jira dashboard |
Leadership and customers | Are we keeping our promises? | A scheduled monthly report, ready to forward |
For admins, SLA data also works in JQL, so it fits into the filters, boards, and dashboards you already maintain. For example, everything due today that's still running:
slaStatus = "In Progress"
AND slaTargetDate >= startOfDay()
AND slaTargetDate <= endOfDay()
Managers who don't write JQL can simply ask the app's Rovo Agent which SLAs are exceeded right now.
Where to start
You don't need a big-bang migration. A month of focused cleanup usually brings the biggest gain.
- Week 1: List every SLA, including the ones in spreadsheets. Mark duplicates and rules nobody can explain.
- Week 2: Merge duplicates into shared SLAs and name an owner for each.
- Week 3: Fix calendars and holidays, then add early warnings for high-priority goals.
- Week 4: Give each audience its own view and schedule the montuhly report.
After a month of clean data, look at where breaches cluster: certain hours, teams, or request types. That's where process changes pay off.
Enterprise SLA management is less about measuring time than about keeping a growing system understandable. Fewer rules, named owners, and honest calendars will do more for compliance than any dashboard. SLA Time and Report gives you all three in one place, across every Jira project, without changing how your teams already work.
Want to see how this would look on your instance? See SLA Time and Report for Jira on the Atlassian Marketplace and test it on your messiest SLA setup.
Over to you: how many SLA configurations does your instance run today, and who owns them? Share your setup in the comments. We read every one.
