Two teams can run the same tickets through the same targets and report compliance figures fifteen points apart, both correctly. The difference is never the data. It is four counting decisions that most reports make silently, and that nobody writes down.
SLA compliance is tickets that met their target divided by total tickets, as a percentage. The arithmetic is trivial; the definitions are not. Before the number means anything you have to decide whether you count tickets or targets, what happens when a ticket meets one clock and misses another, which tickets go in the denominator, and what you exclude. Get those wrong and you will produce a figure that is accurate, defensible and useless.
The Two Formulas
Start with the easy part.
SLA compliance = tickets that met their target ÷ total tickets × 100
Breach rate = breached tickets ÷ total tickets × 100
They are complements, and most teams report one or the other by habit rather than choice. Compliance reads better to a board; breach rate reads better to the people doing the work, because it counts the thing you are trying to reduce. If your figure has been stuck at 94% for three quarters, switching to “six in every hundred” sometimes restarts the conversation.
Decision One: Tickets or Targets?
This is the one that moves the number most, and almost nobody states it.
A ticket carries more than one clock. If it has a first response target and a resolution target, and it met the first but missed the second, is that one breach or half a breach? Tools answer this differently. Several count a ticket as compliant only when every target in its policy was met — so meeting one and missing the other counts as a full breach.
Both conventions are defensible. What is not defensible is not knowing which one your report uses, because it changes the figure substantially on any service desk where response and resolution behave differently — which is most of them. See first response time vs resolution time for why the two clocks diverge in the first place.
Decision Two: Counts Can Exceed Ticket Numbers
Some targets are measured repeatedly across the life of a ticket rather than once. Next-reply and periodic-update clocks restart with each exchange, so a single long conversation can breach several times.
The consequence catches people out in meetings: your total breaches can legitimately exceed your number of breached tickets. Both numbers are correct and they answer different questions. A report that shows one and is described as the other is how a service review turns into an argument about the data instead of the service.
Decision Three: What Goes in the Denominator
Three common choices, three different numbers:
| Denominator | What it answers | Where it misleads |
|---|---|---|
| Tickets resolved in the period | How well did we do on the work we finished? | Ignores everything still open and already breached. Flattering during a backlog. |
| Tickets created in the period | How well did we serve the demand that arrived? | Recent tickets may not have hit their target yet, so the current month always looks good. |
| All tickets active in the period | What did the service feel like at the time? | Hardest to compute, and long-running tickets appear in several periods. |
Resolved-in-period is the most common and the most quietly misleading. A team drowning in an ageing backlog can post excellent compliance simply because the tickets it managed to close were the easy ones. If you report that figure, report open breached tickets beside it.
Decision Four: Exclusions
Every service desk wants to exclude something — tickets raised in error, duplicates, requests that were never really incidents, time lost to a customer who went quiet.
Some of that is legitimate. Paused time while genuinely waiting on a requester should not count against you, and a well-configured clock handles that automatically rather than as a reporting adjustment. But exclusions applied after the fact are corrosive, because there is no natural limit to them. Each one is individually reasonable and the aggregate is a number nobody trusts.
A workable rule: exclusions must be defined before the period, encoded in the tool rather than the spreadsheet, and reported as a count. “96% compliance, 140 tickets excluded” is honest. “96% compliance” with the exclusions buried in a filter is not.
What the Report Is Actually For
A compliance percentage on its own changes no behaviour. It is a scoreboard, and scoreboards are only useful when someone can act on the score. Three additions make the difference:
- Which clock failed. Response breaches and resolution breaches have completely different fixes — routing and cover versus capacity and dependencies.
- Breaches by category and by hour. Breaches concentrated at particular times are a rota problem. Concentrated in one category, they are a skills or tooling problem.
- The trend, not the value. 94% means nothing without last quarter. Direction beats level for every audience except a contractual one.
If the report cannot answer “so what do we change?”, it is being produced for its own sake. That is the most common failure mode of SLA reporting, and it is the reason so many service reviews consist of everyone agreeing the number looks fine.
Where the Numbers Live
Each of the major tools records this differently, and the naming matters when you are reconciling two reports:
- Zendesk reports through Explore and lags ticket updates, so a breach can appear in reporting before the view you were watching shows it.
- Jira Service Management distinguishes
breached()fromeverBreached()— the most recent cycle versus the full history. Mixing them is why triage and monthly numbers refuse to reconcile. - ServiceNow records each clock as its own task SLA, so one incident can carry several with different outcomes.
- Freshservice stamps first response due and resolution due per ticket from the matching policy.
When a figure is disputed, the resolution is almost always that two people are counting different things rather than that one of them is wrong — which is where what counts as an SLA breach is worth agreeing before the meeting rather than during it.
Where InfraCue Fits
InfraCue derives an SLA state for every ticket — on track, at risk, paused, breached or met — from targets set per priority and optionally per category and sub-category, counted in working time against a per-customer schedule. Dashboard and NOC wallboard show live breached and at-risk counts, and ticket reports can be filtered by SLA state and exported to CSV for the period view. The clock pauses genuinely while a ticket waits on a user, an approval or a vendor, which removes the most common reason teams reach for after-the-fact exclusions. Pricing starts at $39 per month (₹2,999), with a 30-day trial and no credit card.
This guide is maintained by InfraCue, an IT operations platform with ticketing, SLA tracking and device monitoring in one console.