> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Working Hours

> Named, reusable sets of weekly windows in a single timezone — the foundation for follow-the-sun escalation and business-hours-aware metrics.

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](/concepts/escalation-policies) 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](/concepts/insights#out-of-hours-paging) insight can classify pages against your organization's real hours instead of a fixed convention.

## What a set contains

| Field      | Notes                                                                        |
| ---------- | ---------------------------------------------------------------------------- |
| `name`     | Display name. Unique within your organization.                               |
| `timezone` | An IANA timezone identifier (for example `Europe/London`). Lives on the set. |
| `windows`  | One or more weekly windows describing the days and times the hours cover.    |

### 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.

```json theme={null}
{
  "name": "UK office hours",
  "timezone": "Europe/London",
  "windows": [
    { "days": [1, 2, 3, 4, 5], "start": "09:00", "end": "17:00" }
  ]
}
```

### 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.

<Note>
  `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.
</Note>

### 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:

| Position | Target      | Condition                    |
| -------- | ----------- | ---------------------------- |
| 1        | UK rotation | `during` **UK office hours** |
| 2        | US rotation | `during` **US office hours** |

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](/guides/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](/concepts/insights#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.

<Note>
  The org default is an internal organization setting. It is **not** exposed on the [public API](/api/overview) or the [Terraform provider](/integrations/terraform) — only the sets themselves and the layer conditions are.
</Note>

## 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](/api/working-hours/working-hours) (full CRUD), through the [Terraform provider](/integrations/terraform#scaling_working_hours) as `scaling_working_hours`, and via the [MCP server](/integrations/mcp) tools (`create_working_hours`, `get_working_hours`, `list_working_hours`, `update_working_hours`, `delete_working_hours`).

## Next steps

<Card title="Set up follow-the-sun escalation" href="/guides/follow-the-sun-escalation" icon="globe">
  Create two working hours sets, gate escalation layers with conditions, and read the resolution preview.
</Card>