On-call schedules
Who is paged, when, and what happens when they are not available.
Incidents & On-Call → On-Call Schedules decides who a page reaches.
Creating a rotation
| Field | Notes |
|---|---|
| Name | The thing being covered — "payments primary" |
| Members | In rotation order |
| Shift length | Weekly is common; daily burns people out slower but fragments context |
| Handover time | When the shift changes |
| Timezone | The rotation's, not the viewer's |
Layers
A schedule can have layers: primary, secondary, a manager escalation. Each is its own rotation, and an escalation policy moves between them.
Overrides
Somebody is ill, or on a plane. An override replaces the on-call person for a window without disturbing the rotation.
Take the override before you go off-grid, not after somebody fails to reach you. An unanswered page escalates, which means it wakes the next person — the cost of forgetting lands on a colleague.
Who is on call now
Every schedule shows the current and next person, with a countdown to handover. This is also what the alert detail page uses when it says who was paged.
Handover
At handover the outgoing person should pass on: what is currently open, what is suppressed and why, and anything that is expected to happen during the next shift.
The Change feed and the maintenance window list cover most of that automatically, which is why they are worth keeping accurate.
Notification preferences
Each person configures how they want to be reached, per severity. Email for
warning, push for high, phone for critical is a reasonable default.
Voice and SMS are opt-in and off by default, and voice never fires on an untargeted broadcast — only on a notification aimed at a specific person. A broadcast that rings phones is how a minor alert wakes an entire team, and it only has to happen once before people stop answering.
Fairness
The schedule view shows how many pages each person received, per shift. Two things fall out of it: an unfair rotation becomes visible, and so does a single noisy rule that happens to fire during one person's week.
Pair it with Alert intelligence — the second is usually a rule problem rather than a rota problem.
Where this behaviour lives: frontend/src/app/oncall/, backend/internal/handler/schedule_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Incidents and on-call — Turning a reading into a page, and a page into a resolved incident.