Skip to main content
A working hours set is a named, reusable group of weekly windows in a single timezone — for example “UK office hours” or “US office hours”. Sets are owned by your organization and managed on the Working Hours page (/working-hours) in the dashboard. They are the foundation for two things:
  • Follow-the-sun escalation — an escalation policy layer can carry a condition that gates whether the layer participates based on the time of day.
  • Business-hours-aware metrics — the out-of-hours paging insight can classify pages against your organization’s real hours instead of a fixed convention.

​
What a set contains

​
Windows

Each window is a { days, start, end } entry:
  • days are ISO weekday numbers — 1 = Monday through 7 = Sunday.
  • start and end are 24-hour HH:MM local times in the set’s timezone.
  • A window whose end is at or before its start crosses midnight into the following day.

​
The timezone lives on the set

A set’s timezone is part of the set — it is never inferred from an on-call schedule a layer happens to target. A “UK hours” condition means UK time whatever the layer pages, and that timezone correctly tracks daylight-saving transitions for you. This keeps a set’s meaning stable no matter where you use it.

​
Layer conditions: follow-the-sun escalation

An escalation policy is an ordered chain of layers. Each layer may carry an optional working hours condition of the shape { workingHoursId, when }, where when is either during or outside:
  • during — the layer participates only while the current instant falls inside the set’s windows.
  • outside — the layer participates only while the current instant falls outside the set’s windows.
A layer with no condition is unconditional and always participates.
outside exists so a night-shift layer never needs a hand-authored mirror set. One “UK office hours” set drives both “during UK hours” and “outside UK hours” conditions.

​
Skip semantics — never wait

When escalation reaches a layer whose condition does not hold, scaling.cloud skips that layer and proceeds to the next one immediately. There is no way to express “hold this page until working hours begin” — a page that has reached an escalation policy was already judged worth waking someone for, so scaling.cloud never makes it sleep.

​
Evaluated at fire time

Conditions are evaluated at the instant escalation reaches the layer — the moment the escalation timer fires — never snapshotted when the incident was created. A page raised at 08:50 that escalates at 09:05 correctly reaches a during-gated day layer. A skip-cascade (skip layer 2, check layer 3, and so on) evaluates wholly at that one firing instant.

​
The backstop — a page never silently dies

If every layer’s condition fails at an evaluation instant, the last layer is paged unconditionally. A page can never silently die to misconfiguration. Because of this backstop, the last layer may page its members outside their own hours — correct for a paging product, but worth knowing when you design the chain. When you save a policy whose layers are all conditional, scaling.cloud shows a non-blocking save-time advisory so the backstop behavior is legible. The advisory never prevents the save; the execution-time backstop is the guarantee.

​
Resolution preview

Because skip-cascades make “who gets paged when” harder to read from the layer list alone, the policy detail page includes a “who would be paged right now” resolution preview. It evaluates every layer’s condition at the current instant and shows which layer the page would reach if an incident escalated now.

​
Follow-the-sun example

To page the UK rotation during UK hours and the US rotation otherwise, author two sets and order two conditional layers: At 14:00 London time, layer 1’s condition holds and the UK rotation is paged. At 22:00 London time it fails, so layer 1 is skipped and layer 2 — whose US hours are active — is paged. If neither holds, the backstop pages the last layer regardless. For a step-by-step walkthrough, see Follow-the-sun escalation.

​
Org default working hours and insights

Your organization can designate one set as its default working hours from organization settings. This default is used by the out-of-hours paging insight: when a default is designated, the metric classifies pages against that set’s windows and timezone instead of the fixed 09:00–17:00 Monday–Friday convention. When no default is designated, the fixed convention remains the fallback. The default is classified against the set’s own timezone and windows, never the timezone of the schedule that was paged and never the gating set of the layer that dispatched the page — that would measure your skip logic rather than human disruption.
The org default is an internal organization setting. It is not exposed on the public API or the Terraform provider — only the sets themselves and the layer conditions are.

​
Deleting a set

A set cannot be deleted while it is referenced, because removing it would change who gets paged:
  • A set referenced by an escalation policy layer condition cannot be deleted.
  • A set designated as the organization default cannot be deleted.
In both cases the delete is blocked with a friendly error. Repoint or remove the references — or clear the org default — first.

​
Managing sets

Working hours sets are also available on the public API (full CRUD), through the Terraform provider as scaling_working_hours, and via the MCP server tools (create_working_hours, get_working_hours, list_working_hours, update_working_hours, delete_working_hours).

​
Next steps

Set up follow-the-sun escalation

Create two working hours sets, gate escalation layers with conditions, and read the resolution preview.