Testing an SLA deadline clock: the checks worth running before you trust it

An SLA deadline is an instant, not a date. That single distinction decides which tools are fit for the job and which are day-counters with an hours field bolted on.

No products are ranked here and nothing is computed on this page. What is here is the model a tool has to implement to be correct, and the questions your contract probably leaves open, because the tool cannot answer a question the agreement never asked.

What to take away

What the clock actually is

"Four business hours" describes a clock that runs during a defined window and stops outside it. To resolve it into a real moment, five things must be pinned down:

Miss any one and the deadline is under-specified. A tool that only accepts a number of hours and a start time has silently chosen answers for all five.

"Close of business" specifies nothing

It gives neither a time nor a place. Whose close of business: the provider's, the customer's, or the site where the work is done? A team across three offices has three closes, several hours apart.

When an office shuts early, the phrase moves. And it says nothing about which day's close applies when the trigger arrives after it.

"By 17:00" is better, but incomplete: 17:00 where? A deadline without a zone can be read two ways, and that gap often exceeds the SLA itself. A four-hour response target between offices eight hours apart is not four hours to either side.

A named zone in the contract still leaves which closure list applies, as the 2027 holiday calendar debate shows.

The fix is unglamorous: state the zone every time, using a named zone rather than an abbreviation, and state the actual instant alongside the interval where you can.

What the tool must model

The last row is the one that quietly separates serious tools from the rest. If the deadline is stored as a wall-clock string, it will drift the moment anything about the zone changes.

The two days a year the clauses disagree

On a clock-shift day, "24 hours from now" and "the same time tomorrow" stop matching. Shift forward an hour: that wall-clock time tomorrow is 23 hours away. Shift back: 25.

A contract using both phrasings is inconsistent twice a year. An SLA in hours will breach or not breach based on which phrasing the tool used.

Two further failures cluster on those days:

A local time that does not exist. When clocks jump forward, an hour of wall-clock time is skipped. A deadline expressed as a local time inside that hour has no instant to point at, and different systems resolve it differently: some to the moment before, some to the moment after. That same skipped hour is one of the nine working hours mistakes that quietly produce a wrong deadline.

A local time that happens twice. When clocks go back, an hour repeats. A deadline at that local time is ambiguous by an hour, and "we met it" and "you missed it" can both be true.

Add to that the fact that regions change on different dates, and in opposite directions between hemispheres. The offset between two offices is not a constant. Any calculation that hard-codes it is wrong for a few weeks each year, and the weeks are different depending on which pair of offices you picked.

None of this is exotic. It is arithmetic that a tool either does with a real timezone database or does not do at all.

Four acceptance tests

Before you commit to anything, run these against it with a stopwatch and a calendar in front of you:

Then fix the contract, not the tool

Most SLA disputes are not calculation errors. They are two defensible readings of an under-specified clause, discovered after the fact.

Write the window, the zone, the calendar source and the pause rule into the agreement. State whether a ticket raised outside hours starts the clock at receipt or at opening, and who may pause it.

Where a specific deadline matters, put the instant in writing next to the interval, with its zone. A disagreement then surfaces at drafting, not at breach.

The tool's job is then to apply a rule you have already settled. That is a job software is good at, and it is a different job from deciding what the rule should have been. For the mistakes that survive even a well-specified clause, see where SLA calculations go wrong; for the day-level equivalents, working hours and adding business days.

Common questions

Should the tool store a computed due moment or recompute it?

Store the inputs and recompute. A stored due moment that has been adjusted in place has lost its derivation, and a rerun with the same inputs must give the same answer for the record to mean anything. That property is plain idempotence, and it is worth testing directly.

What should happen to a running clock when the closure list is updated?

Whatever the agreement says. Pinning the version at the start of the term, pinning it when each clock starts, and always using the current list are all defensible; silence is not.

Is a tool with built-in national calendars better than one without?

Not by itself. Built-in data is convenient and unversioned, which is the wrong trade for anything that has to be reproduced later. Prefer one that lets you supply and pin the list.

How should the tool handle a clock started in one zone and reported in another?

By storing the instant and rendering it per viewer. Storing a local time with no offset is the failure, because the same stored value then means different moments to different readers. What a zone is, as against an offset, is set out under time zone.

Which single test finds the most broken calculators?

A four-hour target triggered one minute before closing. It exercises the window, the roll to the next open day, and the closing-time boundary at once.