The four things an SLA needs
It is worth being precise about the job before choosing a tool, because most attempts fail on one of these rather than on all of them.
What you can do with native Jira, honestly
More than people assume, and less than an SLA needs. It is worth knowing exactly where the line falls, because if your requirement sits on the near side of it you should not buy anything.
What works
- Jira Automation can send time-based reminders. A rule like “if this issue was created more than 24 hours ago and is still not resolved, email the assignee” is straightforward, free, and genuinely useful for simple deadlines.
- A due-date field with a JQL filter and a board. If your commitment really is “finish by this calendar date”, Jira already models that properly, and a saved filter plus a dashboard covers it.
- Automation can set a due date on creation — for example, three days out for a high-priority bug — which gives you something to sort and filter on.
What does not work
- Accumulating time across statuses. Jira stores no field holding “working hours spent in In Progress”. The information exists in the changelog, but nothing sums it, so there is nothing to filter, sort, chart or report on.
- Excluding non-working hours. Automation’s time comparisons are wall-clock. Nights and weekends count, so an overnight issue looks like a failure.
- Pausing and resuming. There is no way to express “stop the clock while this is Waiting for Customer and restart it when it comes back”.
- Compliance reporting. Because no elapsed-time field exists, there is no met percentage, no breach count and no list of what breached.
The short version: native Jira can remind you about a deadline. It cannot measure a service-level agreement.
The two real routes
Jira Service Management
JSM has a mature native SLA engine — goals, calendars, pause conditions, and queues ordered by remaining time. It is the complete answer if you need the rest of the product with it: a customer-facing portal, request types, approvals, a knowledge base. JSM is licensed per agent and bought separately from Jira Software, so it is a licensing decision rather than a setting. Check Atlassian’s current pricing for the numbers.
Buy JSM when you need a service desk. Buying a service desk in order to obtain a timer is the expensive way round, and it changes who is licensed for what.
A Marketplace app on Jira Software
An SLA app reads the changelog Jira already keeps and computes the clock from it. Your projects, workflows and licences do not change; the app adds a panel, some configuration and a report. When you evaluate one, the questions worth asking are narrow:
- Does it support a business calendar, and can you set different ones per policy?
- Can a policy be scoped to specific issue types and priorities, so a tight incident target can coexist with a loose default?
- Does it apply retroactively to issues that are already open, or only to new work?
- Does alerting depend on an event, or does it also sweep on a timer? (See mistake five below.)
- Where does it run — inside your Atlassian cloud, or on the vendor’s servers? Check the listing for the Runs on Atlassian badge if that matters to your security review.
- What does the report actually divide by when it calculates compliance? (See mistake two.)
Five mistakes that make an SLA report untrustworthy
These are the ones we see turn a working setup into a number nobody believes. All five are configuration problems rather than tooling problems, so they follow you between products.
1. Measuring wall-clock time instead of working hours
The single most common cause of an SLA report that everyone ignores. Without a business calendar, every issue raised on a Friday afternoon breaches by Monday, the breach list fills with false failures, and the team correctly concludes the report is meaningless. Fix it by setting a calendar on the policy before you look at any numbers.
2. Counting work still in flight as a miss
If compliance is calculated as met ÷ all issues, then an issue that has only just been created — and is nowhere near its deadline — counts against you. The number drops when the team starts work, which is exactly backwards, and it can never reach 100% on a healthy project.
The correct denominator is settled work: met ÷ (met + breached). In-flight issues are excluded because their outcome is not yet decided. Check which one a tool uses before you compare its output with anything else.
3. A status that both runs and stops the clock
Easy to do when a status is listed in both configuration boxes, and it produces no error. In practice the stop wins, so time spent in that status is never counted — your figures come out flatteringly good, and nobody notices until someone checks a specific issue by hand.
4. A policy with no stop status
If nothing settles the clock, nothing can ever be met. Every matching issue runs until it breaches, and the report shows a wall of failures that has nothing to do with the team’s actual performance. This is the mirror image of mistake three: one makes you look too good, the other makes you look terrible, and both come from the same configuration screen.
5. Alerting that only reacts to events
This is the subtle one, and the most costly. If alerts fire on status changes, comments and edits, then the issue that generates alerts is the issue somebody is working on. The issue nobody has touched for a week produces no events at all — so it crosses its at-risk threshold and then breaches in complete silence.
The dangerous issue is precisely the untouched one. Alerting therefore has to include something that re-evaluates on a timer rather than in response to activity, or it systematically misses the cases you most wanted it to catch.
How Pact handles these
Pact is Hullara’s SLA app for Jira Software. It is one answer among several and this guide has tried to be useful whichever you pick, but it is worth being concrete about how the five mistakes above map onto a real product.
- Working hours are a per-policy setting — pick the team’s IANA time zone (daylight saving is followed), which days are working days, when the day starts and ends, and any holidays; or run the policy 24/7.
- Compliance is reported as Met % (settled), meaning met ÷ (met + breached). Every issue lands in exactly one of four buckets — Met, On track, At risk, Breached — and the four add up to the issue count, so nothing goes missing.
- Mistakes three and four are detected for you. After you save a policy, Pact flags a status that both runs and stops the clock, a policy with no stop status, and two policies sharing a name, right on the settings page.
- Alerting sweeps on a timer. A background sweep runs every five minutes and catches purely time-based breaches on issues with no recent activity. Email is off by default on a new policy and each issue is emailed once per state.
- Nothing leaves your tenant. Alerts go through Jira’s own notification system; there is no Slack integration and no outbound webhook, and the app carries the Runs on Atlassian badge.
Two limits worth knowing. The compliance report scans up to the 300 most recent issues in a project, which suits a regular team review rather than a full-history audit. And the report is per-project — there is no cross-portfolio dashboard.
The issue panel, the policy configuration and the alerting are free on every project at any team size; the report and the CSV exports need a licence above ten users.
Questions
Also worth reading: SLAs on Jira Software without JSM · Pact compared with Time to SLA · the Pact user guide.