Observability and reliability
Rotation design
How to size an on-call rotation so people can sustain it, with a primary, a secondary, written handoffs, and a clear definition of what coverage means.
On-call is the commitment that when production needs a human, a specific person answers, with a laptop, the context, and the authority to act. A rotation is the schedule that makes that true every hour of the year. A rotation designed around heroics fails on the first sick week. A rotation sized for the real load survives it.
The big idea
Think of a fire brigade. A fire station is staffed so that one firefighter being ill does not leave the district uncovered. The number of people on shift comes from the number of hours that must be covered and the time each person can work without burning out. Size the rotation the same way.
Walking through it
Most teams run a primary, who takes the first page, and a secondary, who steps in if the primary does not answer or the incident needs more hands. Escalation continues to a manager or incident commander for events that span several teams.
The minimum size is a hard constraint. Google SRE guidance points to a team large enough that nobody is on call more than a sustainable share of their time. A common floor for 24-hour coverage with weekly shifts is about 8 people, so each person is on one week in eight. Shorter shifts can work with 6 to 8. Below that, illness and holidays leave gaps, and the rest of the team absorbs double duty.
Tip
If you cannot staff eight people for real 24-hour coverage, shrink the scope. Use business-hours on-call with a documented best-effort overnight for lower-severity systems, or split the day across time zones. Claiming 24-hour coverage with three people only hides the cost until someone quits.
Follow-the-sun splits the day across time zones, so engineers are on call during their waking hours. Spotify described a Stockholm and New York pairing in its HumanOps talks. That turns a week of nights into two daytime shifts, with a clear handoff between them.
Handoffs fail silently unless you write them down. Each handoff should answer four questions:
- What is degraded right now?
- What alerts are silenced or tuned?
- Which deploys or migrations are in flight?
- Who is in the middle of an incident, and in what role?
Shift length is a trade-off. Weekly primaries are simple but hard on sleep when pages come overnight. Daily or 12-hour shifts are kinder but add handoffs. New joiners should shadow as secondary for a full rotation before they become primary.
Coverage means more than someone holding a phone. It means the acknowledgment target is met, the laptop and VPN work, the break-glass access has been tested, and the on-call person can roll back or shed load without waiting for approval. If the primary must open three tickets to get production access, you have a notification system, not on-call.
Common mistakes
- Two senior engineers covering every hard week. It is faster in the short term, but the knowledge never spreads, and those two eventually leave.
- A secondary who has never been paged. They fail when the primary is unreachable.
- Handoffs by memory. Write the four handoff answers down every time.
Check yourself
- A team of three claims 24-hour coverage. What is the problem? Each person would be on call far too often to sustain. Shrink the scope, or add people or a second time zone.
- Why does a new joiner shadow before taking primary? So they have seen a full rotation and know the runbooks before they are the first person paged.
Key takeaways
- Size the rotation so no one is on call more than they can sustain.
- Use a primary and a secondary, with written handoffs.
- Coverage means authority and access, not just a phone.
Further learning
Google's chapter on being on-call sets the baseline for shift design and escalation.
Being On-Call (Google SRE book)Proven strategies for on-call engineers to ensure reliable services and maintain sustainable workloads in IT operations.sre.googleRelated
Designing on-call
Sustainable rotations, executable runbooks, toil budgets and a paging policy that keeps humans healthy while production stays covered.
Paging policy
A page is an interruption that costs sleep, so reserve it for user pain, set an acknowledgment target, and route everything else to a ticket. Google's target is at most two incidents per 12-hour shift.
Incident response
Run an incident with clear roles, severity and communication. Mitigate first, debug second, then hand off to the postmortem. Start here for the map of incident pages.