On-call & schedules

How on-call decides who gets paged

On-call management ensures that when an alert fires, the right person is paged at the right time. The system is built from three composable parts:

1. Schedules: define who is on-call during which time window
2. Escalation policies: define what happens if the on-call person does not respond
3. Alert routing: direct alerts from specific monitors to specific escalation policies

---

A shift, start to finish

Being on-call comes down to four moments. Each one links to the reference section further down this page that explains the mechanics behind it.

1. You're on shift

The schedule's active rotation layer determines who that highlighted segment is at any given moment. If a colleague swapped in for you, an override is what makes that show up here instead of the regular rotation. See Schedules below for how layers and overrides work.

2. A page arrives

A monitor fails, a heartbeat goes quiet, or an external alert arrives. Once it crosses its threshold, alert routing picks an escalation policy (or falls back to a broadcast), and that policy's first step fires — immediately, unless the step itself has a delay. See Alert routing below.

3. Acknowledge, or let it escalate

Acknowledging is what stops this from advancing — it does not require being the person a step named; any team member with access can acknowledge. Alongside escalation steps, your own personal notification chain reaches you across channels in parallel (push, then email, then SMS, then voice, each with its own fallback delay). See Alert & incident flow for the full timing picture.

4. Hand off to the next person

When the rotation layer's cadence turns over (daily or weekly, depending on the layer type), the schedule resolves to the next person automatically — nothing to hand off manually unless you use an override to swap shifts ahead of time.

---

Schedules

A schedule is a calendar of on-call shifts. It is built from one or more rotation layers, each covering a period of time with a set of team members who rotate through it.

Rotation types

Type	Coverage window	Rotation cadence
Daily	24 hours	Every day
Weekly	7 days (Mon–Sun)	Every 7 days
Business Hours	Mon–Fri, 09:00–18:00	Every day
Nights	Outside business hours	Every 7 days
Weekends	Sat–Sun	Every 7 days
Custom Hours	Any start/end + active days	Every day

The cadence is fixed by the rotation type (it is not a separate "daily or weekly" choice): daily, business-hours, weekday, and custom-hours layers hand off every day; weekly, nights, and weekends layers hand off every 7 days.

Layers can overlap. There is no per-layer priority setting. When more than one layer covers the same moment, an active override always wins; otherwise the first layer by position (the order shown in the editor) is used. Use multiple layers to model patterns such as:

• Primary on-call (24/7) with a backup layer that only activates on weekends
• Day shift and night shift with different engineers

Overrides

An override lets you replace the on-call person for a specific time window without changing the underlying rotation. Common use case: an engineer goes on holiday and a colleague takes their shift.

Create an override from the schedule detail page by clicking Add override, selecting the replacement person, and defining the time window.

---

Escalation policies with schedules

When you add a Schedule as a notification target in an escalation policy step, the platform resolves the current on-call person from that schedule at the moment the step fires. This means you do not need to update your escalation policies when rotations change; the schedule handles it.

Step target	Resolves to
Schedule ("Primary On-Call")	Whoever is on-call right now on that schedule — changes as the rotation turns over
User ("[email protected]")	That specific person, always — does not change with any rotation
Channel ("ops-slack")	The same Slack channel, always

---

Alert routing

Alert routing rules determine which escalation policy receives alerts from which monitors. Rules are evaluated in priority order (lowest number first); the first matching rule wins.

A rule can match on any combination of:

• Monitor type (http, ping): leave blank for any type
• Monitor tag: one tag per rule; leave blank for any tag
• Alert severity (critical, warning, info): leave blank for any severity
• Labels: match on labels carried by the alert

Each field is independently wildcard-or-exact: a blank field matches anything, a set field requires an exact match. All set fields are AND-ed together. A matching rule can pin a specific escalation policy or force a broadcast.

Each rule routes to either a specific escalation policy or Broadcast to all team members (which dispatches the alert to every enabled workspace notification channel, bypassing on-call rotation).

If no rule matches, the default routing rule applies (all unmatched alerts go to the default escalation policy).

---

Related

• Concepts: Alert & incident flow
• Concepts: Escalation
• Concepts: Notifications
• Tutorials: Slack alerts in 5 minutes