Maintenance Sla Clock

The defect

A work-order SLA is almost always now - createdAt. So the clock runs while the tenant has not replied to three attempts to arrange access, while a part is on back-order, over a public holiday, and at 3am on a Sunday against a business-hours target.

None of that is time you are failing to act. The team knows the number is wrong, so they start managing the number instead of the work: closing and reopening tickets, logging a templated auto-reply as "first response", raising a fresh ticket for the same fault. **The metric improves and the tenant's experience does not** — which is worse than having no metric, because you have lost the signal and are still paying to produce it.

  evaluateSla(order, target, now);
  // { resolutionMinutes: 120, pausedMinutes: 240,
  //   detail: "120m countable of 480m allowed; 240m excluded as paused" }

Response is not resolution

Collapsing "we acknowledged it" and "it is fixed" into one number hides the case everyone actually complains about: fast acknowledgement, then weeks of silence. The response clock stops at first response; the resolution clock keeps running. They breach independently.

Pausing is also where a bad number hides

This is the honest mechanism and the obvious place to bury a failure, so the same package that lets you exclude the time makes the exclusions visible:

  pauseReview(orders, target, now);
  // [{ workOrderId: "…", pausedMinutes: 410, countableMinutes: 10, ratio: 41, reasons: ["awaiting_tenant"] }]

Three weeks "awaiting tenant" may be a tenant who genuinely will not respond, or one attempted phone call in week one. This does not decide which — it puts the ratio in front of someone who can.

Business hours

A ticket opened Friday 5pm has three days of elapsed time by Monday, none of it working time. Hours are evaluated in the site's own timezone via Intl, with optional site holidays.

An unrecognised timezone counts time rather than zeroing the clock. Silently counting nothing would report perfect SLA compliance for a configuration typo, which is the worst available failure mode for a compliance metric.

On the implementation

Time is counted by sampling minute by minute. That is deliberately unclever: interval arithmetic across DST transitions, overlapping pause periods and holiday boundaries is exactly where subtle errors live, and a minute loop is obviously correct at the cost of being slower than it needs to be. Work orders run hours to weeks, so the cost is irrelevant and a wrong SLA number is not.

| not included | why | |---|---| | Storing work orders or pauses | pure functions over your records | | Deciding when to pause | that is a human judgement about the job | | Escalation, routing, notifications | ticket-triage-router for routing | | Cost or billing | different problem |