SLA Clock Template: Start, Pause, Resume and Stop

Two teams can agree on a four-hour target and still disagree about whether a request was late. One counts the weekend. Another subtracts time spent waiting for a document. A third restarts the timer after reassignment.

This SLA clock template turns those assumptions into a reviewable specification. Copy the definition record, transition rules and event ledger into a shared document or spreadsheet. Then use the worked example to check the calculation before anyone configures software.

The resource is for an operational response, review or resolution metric—not uptime percentages or service-credit calculations. Its sample rules are recommended design choices for a fictional internal service. An approved agreement or policy takes precedence; do not use the template to silently change an existing commitment.

Copy the SLA clock definition record

Create one record per metric and rule version. First response and final resolution need separate records even when they belong to the same request. Replace every bracketed value; write “none” where a field genuinely does not apply.

If you have not yet agreed on service scope, targets or responsibilities, begin with the broader workflow SLA design guide. This resource starts where that agreement becomes a precise clock.

Specify transitions without erasing elapsed time

Use the table below as a default operating model, then reconcile it with the chosen system and approved commitment. These labels are a specification convention, not a claim that every product implements identical states.

Treat breach as a separate result flag. A request can be paused and already breached at the same time. In its own product documentation, Zendesk distinguishes active, paused and closed targets from their breached variants; it also shows that pause behavior depends on the metric. Do not assume a “pending” label pauses every target.

Atlassian’s SLA conditions documentation separately defines when measurement begins, pauses and finishes. Use those distinctions when writing the specification, rather than borrowing a status name without checking its effect.

Keep an event ledger that can explain the answer

Copy this header into your working record. Use one row for each event; do not overwrite a pause with the latest status. Keep evidence in an approved location and reference it rather than copying sensitive request content into a broadly shared sheet.

Request ID | Clock ID/version | Cycle ID | Event ID | Event type
Occurred at (UTC or offset timestamp) | Recorded at | Actor/source
Reason code | Evidence reference | Related event ID
Target minutes | Calendar ID/version | Reviewer/correction reference

Event types should include start, pause, resume, stop, cancel and correction. A resume references its matching pause; a correction references the event being corrected. Keep the original entry and a dated correction trail.

• Missing or ambiguous time: mark calculation “needs review.” Do not invent midnight or the last update time.
• Repeated event: use a stable event ID to identify a duplicate; count one logical event once.
• Late arrival: preserve both occurred-at and recorded-at. A reviewer checks the supporting evidence before an approved recalculation.
• Conflicting order: resolve events that appear before start or after stop. For simultaneous events, specify precedence—for this template, evidenced completion ends the cycle before a pause can affect later time.

Calculate only the time that qualifies

For a cycle starting at S and ending at E, counted time is the duration inside the cycle and the approved working calendar, with permitted pause intervals removed:

Counted minutes = duration( [S, E) ∩ working windows − union(valid pauses) )
Remaining minutes = max(0, target minutes − counted minutes)
Overrun minutes = max(0, counted minutes − target minutes)

The interval notation [S, E) includes the start and excludes the end. Merge overlapping pause intervals before subtracting them. Also intersect pauses with working windows: a pause over a closed weekend does not subtract the weekend twice.

For a manual calculation, split the cycle at each calendar opening/closing, pause, resume and stop. Record each segment’s start, end, eligible/not-eligible reason and counted duration. Sum only eligible segments. A simple end timestamp minus start timestamp measures wall time, not business time.

Keep calendar exclusions separate from pauses

Closed hours belong to the calendar; waiting for requester evidence belongs to a pause rule. Atlassian’s calendar documentation and Zendesk’s schedule documentation show why the time zone, working windows and holidays must be explicit. The particular product’s configuration still needs testing.

Store event instants as UTC or timestamps with an offset, and keep the named calendar time zone separately. During a daylight-saving transition, a local time without an offset can be ambiguous or nonexistent. Have the implementer validate those cases against the actual calendar engine; do not “fix” them by guessing an offset.

Agree on the boundary and warning rules

This template recommends “completed on time” when final counted time is less than or equal to the target. At the exact target, an unfinished request is due now; after additional eligible time, it is breached. A pause preserves an existing breach. Use a different boundary only when the governing commitment specifies it, and test that difference explicitly.

A warning can use counted time—for example, at 180 of 240 allowed minutes—but it also needs an operational response. Name who reviews the request and by when. While a request is paused, show “paused—remaining allowance X” rather than a confident deadline that assumes an unknown resume date. Review paused cases on their own cadence.

Worked example: a four-business-hour review

Fictional example: an internal service team reviews standard requests within 240 business minutes. Clock REVIEW-01 v1 starts when complete intake is accepted and stops when the reviewer records a decision and its evidence. The request need not be approved: an evidenced rejection also completes this review metric.

Calendar OPS-CHI v1 is Monday–Friday, 09:00–17:00 America/Chicago, with no closures on the dates below. Only waiting for specifically requested requester evidence is a permitted pause. The reviewer records the missing item and an evidence link; the clock resumes when that item is received. Reassignment does not reset it. The team reviews paused cases each business day at 10:00. A warning at 180 counted minutes routes to the service lead for review within 30 business minutes; a breach routes immediately to the operations manager for a recovery action within 30 business minutes. These are example choices, not benchmarks.

The counted segments are Friday 15:00–16:00 (60 minutes) and Monday 10:00–12:30 (150 minutes): 210 minutes total, 30 minutes unused, completed on time. Friday 16:00–17:00 and Monday 09:00–10:00 are excluded by the pause. The rest is outside the working calendar.

Without the pause, those dates contain 330 working minutes. Subtract the 120 paused working minutes—not the entire weekend-length pause—to reach 210. After the Monday resume, the projected due time is 13:00 if nothing else changes. The 180-minute warning occurs at 12:00 Monday; completing at 12:30 does not make the earlier warning a false calculation.

Use these checks before approving the clock

The service owner approves the definition; an implementer configures it; an operator runs the cases; the reporting owner reconciles results. Record expected result, observed result, evidence, defect owner and retest outcome for each case.

Before release, also test duplicate events, a resume delivered late, cancellation, priority changes, multiple matching target rules and stop-during-pause. If the definition changes, issue a new version with an effective date. Decide explicitly what happens to in-flight cycles; do not mix old and new logic in one unexplained performance total.

For reporting, keep completed-on-time, completed-breached, active, paused, cancelled and unresolved-data counts visible. If you calculate a completion compliance rate, state its denominator—for example, eligible completed cycles with resolved evidence. Show exclusions and unresolved records alongside it so a clean percentage does not conceal missing data.

Where Workhint fits

The specification works as a shared document without Workhint. When agreeing timing rules involves several teams, Workhint’s Workflow Engine describes support for requests, assignments, approval steps and required information before progression. Those capabilities are relevant to routing a proposed clock definition through its reviewers.

The workflow automation software solution describes forms, roles, routing and stage ownership. These can inform the coordination design around clock-rule changes and exception reviews. They do not establish support for this exact SLA arithmetic, holiday calendar, pause logic or event-ledger implementation. Validate those requirements separately against the actual configured system.

FAQ

Does every waiting status pause an SLA?

No. The approved metric definition and configured system determine which intervals count. Map each permitted pause to its reason, evidence, authorized role and resume event.

Should changing the owner restart the clock?

Not in this template’s default model. Keep the accumulated time when responsibility moves. If your commitment defines a separate stage metric, give it its own cycle rather than overwriting the end-to-end result.

Can this template automatically calculate due dates?

No. It is an inline specification and manual verification method, not a programmed calculator. A production implementation needs tested calendar handling, event processing and reporting.

What should happen when a pause is disputed?

Keep its evidence and original result, flag the calculation for review, and route it to the named decision owner. Record any approved correction rather than quietly deleting the pause or treating uncertain data as a pass.