Most teams spend their energy choosing SLA targets — four hours for first response, two business days to resolve a P2 — and almost none on the question that actually determines whether they hit them: how does the clock run? A "four-hour response SLA" means something completely different depending on whether those four hours include the overnight, the weekend, and the three hours the ticket sat waiting on the customer for their order number. Two teams with the identical target on paper can report wildly different breach rates purely because one counts wall-clock time and the other counts working time. The clock, not the target, is where SLA reporting becomes honest or becomes fiction.
Wall-clock time is almost always the wrong measure
If you run a 9-to-5 support team and your SLA clock ticks 24/7, a ticket that arrives at 4:55 p.m. is already most of the way to breach before anyone could possibly see it, and a Friday-evening ticket is doomed before Monday. Measured against wall-clock time, a perfectly responsive team looks like it breaches constantly — not because it is slow, but because you are crediting it for hours it never agreed to work. The fix is a business-hours calendar: the SLA clock only runs during your stated coverage hours, and pauses outside them. With a business-hours clock, that 4:55 p.m. ticket has its four-hour response window resume the next morning, and your breach numbers suddenly reflect performance instead of timezone luck. Teams that promise 24/7 coverage are the rare exception where a round-the-clock clock is correct — and they had better be staffing for it.
Stop-the-clock: not all waiting is your fault
The second great distortion is counting time the ticket spent waiting on someone other than your team. A ticket parked in "waiting on customer" while the requester digs up their account number is not your team being slow — it is the customer's response time, and charging it against your SLA punishes you for their delay. The same goes for time a ticket sits with engineering on an escalation, governed by an internal OLA rather than your customer-facing SLA.
The mechanism is a set of stop-the-clock states. When a ticket enters "waiting on customer," the resolution clock pauses; when the customer replies, it resumes. This is exactly the paused-state logic that keeps resolution-time metrics fair, and it has to apply to SLA measurement too or the two numbers will disagree and nobody will trust either. The discipline it demands: agents have to actually set the waiting status, because a clock that only pauses when someone remembers to flip a field will quietly over-report breaches.
Where the rules live, and where they go wrong
The trap is encoding these rules inconsistently — a business-hours calendar on response time but a 24/7 clock on resolution, or a pause state your reports ignore. When that happens, the dashboard and the lived reality drift apart, and the first sign of trouble is an angry customer, not a metric. The same clock logic should govern both your live SLA timers and your after-the-fact compliance reporting, so "are we about to breach?" and "did we breach last month?" are answered by the same math.
Making the clock honest in the tool
This only works if the tool models the calendar and the pause states natively rather than asking you to subtract them by hand in a spreadsheet later. Hitt Hosting Desk runs business-hours SLA policies with breach detection on a calendar you define, pauses the clock in waiting states, and reports compliance on the same paused, business-hours basis it uses for the live timers — so the breach you see in the report is a breach that really happened. Plans run 7.99 dollars per seat at the entry tier and 19 dollars at the higher tier; see pricing and the guide to designing SLA policies you can actually hit.
The honest test
Your SLA clock is right when a breach on the dashboard corresponds to a moment your team genuinely could have responded faster and did not — no breaches manufactured by overnight hours you never staffed, no breaches charged for time the customer kept you waiting. If your team feels the breach numbers are unfair, do not argue with them about effort; go look at the clock. The fairness of an SLA lives entirely in how its time is counted.