On-Call Rotation

An on-call rotation is the schedule and process that determines who is responsible for responding to alerts and incidents outside normal working hours, and how that responsibility passes from one person to the next. Its job is to make sure something is always being watched, and that at any given moment it's unambiguous exactly who's watching it.

Key components

• A clear schedule with unambiguous handoff times — exact start and end times for each shift, stated in a single agreed time zone, so there's never a moment where two people both think they're off and neither is actually on.
• An escalation path — who gets notified, and after how long, if the primary on-call person doesn't acknowledge an alert within a defined window, so a response doesn't depend entirely on one person being reachable.
• Access to the runbooks and tools needed to act — the on-call person needs standing access to the systems, dashboards, and Runbook procedures the job requires before an alert fires, not access requested and granted at 3am while a system is down.
• A sustainable rotation frequency — enough people in the rotation, and a shift length, that no single person carries a disproportionate share of the burden week after week.
• Alert routing and acknowledgment tracking — a defined way alerts reach the current on-call person (paging tool, phone, chat), and a record of whether and when they were acknowledged, so a missed alert is visible rather than silent.

Why the escalation path matters as much as the primary assignment

It's tempting to treat the schedule as the whole job: as long as someone is named as on-call for a given window, the rotation is "done." But naming a primary on-call person solves nothing on its own if that person is asleep, on a flight, or their phone dies — a rotation with no escalation path stalls completely the moment the one person on call is unreachable. The escalation path is what turns "this person is supposed to respond" into "someone will actually respond," by defining a secondary, then a manager or wider team, and a timeout for each step. A rotation is only as reliable as its worst-case path, not its best-case one.

Common pitfalls

• Handoff times ambiguous or undocumented — without an exact time and time zone for each handoff, it's genuinely unclear who's responsible at a given moment, especially across time zones or around daylight saving changes, and an alert can land in the gap.
• No escalation path — if the primary on-call engineer is unreachable and there's no defined next step, nobody responds at all, no matter how good the schedule looks on paper.
• The same few people carrying most of the rotation — an understaffed rotation, or one where people habitually cover for each other, quietly concentrates the load on a handful of people until they burn out or leave.
• No access set up in advance — an on-call person who has to request system access or find the current runbook after an alert fires loses critical response time to something that should already be in place.
• Alerts with no acknowledgment tracking — without a record of whether an alert was seen and by whom, a missed page can go unnoticed until someone else eventually escalates it manually.
• Rotation calendar out of sync with reality — a schedule that isn't updated for vacations, swaps, or new hires leaves people paged who aren't actually on call, or nobody paged who is.

Learn more

• Runbook for the step-by-step procedures the on-call person actually executes once an alert fires.
• Incident Response Plan for what happens once an on-call response escalates into a declared incident, including roles and communication.
• Service Level Agreement for the response-time commitments an on-call rotation typically exists to meet.