On-Call Rotation

An on-call rotation is a calendar of who is responsible for responding to production alerts during defined time windows. The primary on-call acknowledges pages first; secondary and escalation policy steps cover gaps when the primary is unavailable or needs help.

Rotations turn “someone should look at this” into “this person is accountable right now.” That accountability is foundational to structured incident management and directly affects MTTD.

Why it matters

Without a rotation, response depends on who happens to be online — hero culture, uneven burnout, and slower pages. A fair rotation spreads load, makes coverage gaps visible, and pairs with runbooks and escalation so the on-call engineer is not alone. Practical design guidance lives in How to Build an Effective On-Call Rotation guide.

Example

A six-person team runs weekly primary rotation: each engineer is primary one week every six, with a fixed secondary partner. Handoff happens Monday 09:00 with five minutes of “open incidents, noisy alerts, deploys this week.” Pages route only to primary and secondary — not the whole team — which reduces alert fatigue.

Common mistakes

• No secondary — vacations and sick days happen.
• Rotations that exceed ~25–33% duty per person without compensation or relief.
• Handoffs with no context — the next on-call rediscovers active issues.
• Rotation docs separate from paging config — the schedule in Slack must match the pager.

Model your rotation with the on-call schedule template, then wire it to escalation policies and service ownership. Review fairness quarterly: if the same people always get the hard weeks, fix the process, not the people.