A four-hour first-response SLA that started Monday at 15:00 does not breach at 19:00 — it breaches Wednesday morning, once the weekend and Tuesday's closed hours are excluded. A surprising number of helpdesks get this arithmetic wrong, and an even larger number get pausing wrong in a way that quietly moves the deadline the wrong direction.
Support teams that promise a first-response time almost always mean it in business hours, not wall-clock hours — a four-hour SLA is not supposed to mean a ticket filed at 4pm on Friday gets an automatic breach notice at 8pm the same evening, with a support team that doesn't work evenings or weekends. And yet a striking number of helpdesk tools, including some fairly established ones, calculate the deadline as if the clock never stops. If you've ever had an SLA dashboard show a breach that nobody actually missed, or a healthy SLA that everybody in the room knows was actually missed, the calculation underneath is worth checking directly.
The calendar clock and the business clock are different arithmetic
A calendar clock counts elapsed wall time without exception: four hours after 3pm Monday is 7pm Monday, full stop. A business clock counts only the hours a support team is actually working, and — critically — advances the deadline over any hours outside that window rather than counting them. These produce wildly different answers for the same ticket, and the gap gets larger the closer a ticket lands to the end of a working day or the start of a weekend.
Worked example: Monday 15:00, four-hour SLA, 09:00–17:00 business hours
Take a ticket that arrives Monday at 15:00, a four-hour first-response SLA, and a support team working 09:00–17:00, Monday to Friday, with no work on weekends.
Calendar-hours arithmetic (wrong, but what a naive implementation produces): 15:00 + 4 hours = 19:00 Monday. The system fires a breach warning at 19:00 the same evening, hours after the office closed, for a ticket that no reasonable SLA policy actually expected answered outside working hours.
Business-hours arithmetic (correct): the clock has from 15:00 to 17:00 Monday to work with before hours run out — that's 2 hours of the 4-hour budget consumed, leaving 2 hours remaining. The clock is closed all evening Monday, all of Tuesday only if Tuesday is also closed (it isn't in this example — assume normal weekday hours), so it resumes at 09:00 Tuesday. Two more hours of business time from 09:00 Tuesday lands the deadline at 11:00 Tuesday.
The point isn't the specific numbers — it's that every hour outside the configured business calendar has to be skipped entirely, not counted, and the calculation has to walk forward through the calendar day by day if the remaining budget spans more than one working day. A calendar clock is a single addition. A business clock is a small scheduling algorithm, and it's easy to implement in a way that looks right for same-day tickets and quietly breaks for anything spanning a weekend or holiday.
Holiday calendars aren't optional extras
A business-hours clock that only knows about a weekly Monday–Friday, 9-to-5 pattern still gets public holidays wrong, and public holidays are exactly the days a support team is least likely to be available and most likely to have an SLA dashboard lighting up incorrectly the next morning. A correct implementation needs a holiday calendar as a first-class input to the same clock — a configurable list of specific dates (and, for teams spanning regions, potentially more than one calendar) that get excluded from the available-hours calculation the same way weekends are. Skip this and every SLA that spans a holiday silently reports on the wrong deadline, without any visible sign that anything's wrong until someone manually checks the math.
Pausing correctly, and the naive bug that gets it backwards
Most SLA policies allow the clock to pause while a ticket is waiting on something the support team doesn't control — most commonly, a status like "waiting on customer," where the agent has asked a question and is blocked until the customer answers. This is the right instinct: an SLA is supposed to measure the support team's responsiveness, not penalise them for a customer who takes three days to reply to a clarifying question.
The correct implementation stops the elapsed-time clock the moment the ticket enters the paused state, records the timestamp, and — when the ticket comes back out of the paused state — resumes the same clock from where it left off, adding only the time that passes after that point. The deadline effectively shifts later by exactly the duration of the pause, because the paused hours never counted against the SLA in the first place.
The naive bug — and it shows up more often than you'd expect — is calculating the deadline once, up front, and then adding the pause duration onto that fixed deadline after the fact, as a kind of correction applied retroactively. This sounds equivalent to pausing the clock, and in the simplest cases it produces the same number, but it breaks the moment a ticket is paused more than once, or paused while other business-hours boundaries (a weekend, a holiday) fall inside the pause window. Adding a flat duration onto a deadline assumes every hour of the pause would otherwise have counted as business time, which isn't true if part of the pause happened over a weekend — you'd be crediting the ticket with pause time it never actually needed, shifting the deadline further out than the policy intends. Pausing correctly means the clock genuinely stops accumulating elapsed business time and resumes from exactly where it stopped, rather than the deadline being recalculated with an offset bolted on afterward.
Why SLA history has to be recorded, not derived
There's a design decision underneath all of this that determines whether any of the above is actually trustworthy after the fact: does the system record every state change — ticket created, clock started, paused, resumed, first response sent, deadline recalculated — as an immutable, timestamped event, or does it derive the current SLA status on demand by reading the ticket's current fields and running the arithmetic fresh each time?
A derived approach looks fine until someone asks why a specific ticket breached, three weeks after the fact, possibly in the middle of a dispute with a customer about whether the response really was late. If the system only stores current state — current status, current pause flag, a single "paused at" timestamp that gets overwritten every time the ticket pauses again — then the history of exactly when it paused the first time, what the deadline was before a later reconfiguration of business hours, or how many separate pause periods occurred, is simply gone. You can't reconstruct a decision from a system that never recorded the decision being made, only its latest state.
An append-only history table — one row per event, never updated or deleted, each with its own timestamp and the values that were true at that moment — solves this by construction. The current SLA state becomes something you compute by replaying the event log rather than something stored and mutated in place, which means the full history is always available for exactly the situation where you need it: explaining a breach, auditing whether business hours were configured correctly at the time, or investigating why a customer's escalation email says a promise was missed. It also happens to be the same pattern that fixes the concurrency problems in ticket deduplication — treating history as a sequence of recorded facts rather than a mutable current-state field is a recurring theme in building support tooling that holds up under real, messy usage rather than just the demo case.
The mechanics here matter well beyond the ticket that happens to breach — a support team that can't trust its own SLA dashboard ends up either ignoring it or manually recalculating deadlines in a spreadsheet, both of which defeat the point of having automated SLA tracking at all. See how business-hours calculation, holiday calendars, pausing and the breach-explainability screen fit together on SLA management, or the wider ticket lifecycle on Service Desk. If you're comparing this against Zendesk or Freshdesk's SLA tooling specifically, our Zendesk and Freshdesk comparisons and the general compare page cover what each includes at their respective tiers, and Pricing has Stillpoint's own plan detail.