The short version
Why Jira Software has no SLAs
This is a product boundary rather than an oversight. SLAs are a commitment made to somebody outside the delivery team — a customer, an internal requester, a contract — and the machinery for managing that relationship is what Jira Service Management is. So Atlassian put the SLA engine there: goals, calendars, pause conditions and SLA-based queues are all JSM features.
Jira Software teams keep hitting the same wall anyway, because plenty of work has a deadline without having a service desk around it. A security team promising triage of reported vulnerabilities within one working day. A platform team promising to pick up blocked builds within four hours. A QA team promising a verdict on a release candidate before end of day. None of those needs a portal. All of them need a clock.
JSM is licensed per agent and bought separately from Jira Software, so the upgrade is not a toggle — it changes who is licensed for what. Check Atlassian’s current pricing for the numbers; they change, and this page deliberately does not quote them. The point is structural: you are being asked to buy a service-desk product to obtain a timer.
What an SLA actually requires
Before comparing routes it helps to be precise about the job, because most homemade attempts fail on one of these five points rather than on all of them.
- A clock that follows status, not the calendar. The timer must run while an issue is in the statuses you consider “being worked”, and stop when it reaches one you consider done. Time parked in a waiting status should not count against you unless you say it should.
- Working hours. A four-hour SLA on a ticket raised at 16:30 on a Friday is not breached by Monday morning. Without a business calendar every out-of-hours issue is reported as a failure, and the report becomes something nobody trusts.
- An at-risk threshold. A breach alert is a post-mortem. The alert that changes an outcome fires before the deadline — commonly at 80% of budget.
- Breach detection that does not depend on an event. The dangerous issue is the one nobody touches. If your alerting is triggered only by status changes or edits, an issue that quietly sits past its deadline generates nothing at all.
- Evidence. Someone will eventually ask “did we hold to it?”, and the honest answer needs a report: how many met, how many breached, which ones, and by how much.
The three routes, honestly
Native Jira Software
You can get part of the way. Jira Automation can send a reminder a fixed time after an issue is created or transitioned, and JQL can filter on dates, so a rule like “email the assignee 24 hours after this was raised if it is still open” is entirely doable and costs nothing. That covers a simple deadline reasonably well.
What native tooling cannot do is accumulate time across statuses, subtract non-working hours, or report met and breached counts. There is no field holding “working hours spent in In Progress”, so there is nothing to filter, sort or chart on. If a simple elapsed-time reminder is genuinely all you need, use Automation and stop reading — it is free and it works.
Jira Service Management
The complete answer, if you need the rest of the product with it. JSM’s SLA engine is mature, supports pause conditions and multiple calendars, and drives queues so agents work in deadline order. Buy it when the portal, request types, approvals and knowledge base are things you want — not merely as a way to obtain a timer.
An SLA app on Jira Software
A Marketplace app reads the same changelog Jira already keeps and computes the clock from it. Nothing about your projects, workflows or licences changes; the app adds a panel, some configuration, and a report. This is the smallest change that produces a real SLA, and it is what Pact does.
How Pact does it
There is a working SLA before you configure anything
Open any issue, choose Apps → SLA, and the panel already shows a sensible default SLA derived from that project’s own statuses. Most SLA tooling starts with a blank configuration screen, which is where evaluations quietly die. Pact starts with something on the screen and lets you correct it.
Policies, scoped to the work they belong to
In Project settings → SLA a policy names the statuses where the clock runs, the statuses that settle it, a budget in working hours, an at-risk percentage (80% by default), and a calendar — business hours or 24/7. A policy can be narrowed with Applies to to particular issue types and priorities, so a tight SLA on high-priority bugs sits alongside a loose one on everything else. Tick nothing and it covers the whole project.
Policies apply retroactively to issues that are already open, computed from their history, so you see real states the moment you save rather than waiting for new work.
Warnings for the policies that break silently
Three misconfigurations are easy to make and produce no error — a status ticked as both running and stopping the clock (the stop wins, so that time is never counted), a policy with no stop status at all (nothing can ever be met, so everything eventually breaches), and two policies sharing a name. Pact lists these on the settings page after you save. They are warnings, not blockers.
Alerts that are opt-in, and that fire without an event
Each policy can email the reporter and assignee when an issue goes at-risk and again when it breaches, once per state. The checkbox is off by default on a new policy, on purpose: a policy you have just written is a guess, and the sweep runs every five minutes, so turning alerting on is a decision you make once the thresholds look right. That five-minute sweep is also what catches the purely time-based breach — the issue nobody touched, which generates no event for anything else to react to.
Mail goes through Jira’s own in-tenant notification system. There is no Slack integration and no outbound webhook, which is a deliberate constraint rather than a missing feature: both would send your data to a server outside Atlassian and forfeit the Runs on Atlassian badge.
A report that adds up
Run report scans in the background and stores the result, so reopening settings shows the last report instantly with the timestamp it was built. Every issue lands in exactly one of four buckets — Met, On track, At risk, Breached — and the four add up to the issue count. The headline figure is Met % (settled), which is Met ÷ (Met + Breached): work still in flight is not counted as a miss, so starting a piece of work cannot make your compliance number drop.
A limit worth knowing before you install: the report scans up to the 300 most recent issues in the project. That is the right size for a team’s weekly or monthly review and the wrong size for a full-history audit of a very large project. The per-issue panel has no such cap — it computes live from that issue’s own changelog.
What is free, and what is not
Pact’s split is functional rather than purely seat-based. Free on every project at any team size: the issue panel with its live countdown, the full policy configuration, and the at-risk and breach emails. The alerting — the part most teams actually adopt an SLA tool for — is in the free surface.
Paid, and free for sites of 10 users or fewer: the compliance report, the breached-issue drill-down, and both CSV exports. Above ten users those need an active licence, and an admin can start a free trial from Jira Settings → Marketplace apps → Manage apps. From $1.20 per user per month at the first paid tier, tapering with size.
Pact carries Atlassian’s Runs on Atlassian badge, meaning it runs and stores its configuration entirely inside your own Atlassian cloud with no external servers. Worth saying plainly: roughly a third of the Marketplace carries that badge, so it is hygiene rather than a differentiator — it helps you pass a security filter, not win a category.
Questions
Also worth reading: how to track SLAs in Jira · Pact compared with Time to SLA · the Pact user guide.