Free — no signup required

Rotation Topologies: Scheduling for Sleep

3 min read

How you arrange the schedule determines how much of an engineer's life on-call consumes. There is no universally correct answer — only trade-offs between cost, team size, and human impact.

1. The Weekly Rotation (Traditional)

Structure: One engineer is on-call 24/7 for a full week, typically Monday handover to Monday handover.

Pros: Simple to schedule. Engineers "get it over with" and then have several uninterrupted weeks. Handover happens only once per week, reducing context-switching overhead.

Cons: Extremely grueling if the service is noisy. A week of five-pages-per-night means the engineer is functionally non-functional by Wednesday. High burnout risk. Also creates a perverse incentive: if you're going to have a bad week anyway, why bother fixing alerts mid-shift?

2. The Split Shift (Weekday/Weekend)

Structure: Separate rotations for weekdays (Monday–Friday) and weekends (Saturday–Sunday). Engineers rotate through each independently.

Pros: You don't sacrifice your entire weekend just because you had a weekday shift. Weekend shifts are shorter and can be compensated differently (higher stipend) to reflect the higher personal cost.

Cons: More scheduling complexity. Engineers need to track two separate rotation calendars. Handover happens more frequently, requiring tighter runbook discipline.

3. Follow-the-Sun (The Gold Standard)

Structure: Teams in three geographic regions — typically Europe, Americas, and Asia-Pacific — each cover an 8-hour window during their local business hours. At the end of each window, the outgoing team hands off active incidents and context to the incoming team.

Pros: Zero night shifts. Every engineer sleeps in their own bed every night. Incidents get fresh eyes at every handover. This is the model that scales to truly global, always-on services.

Cons: Expensive. Requires fully staffed, capable engineering teams in three distinct regions. Handover quality is critical — a poor handover means the incoming team inherits an incident with no context. Requires disciplined incident documentation.

4. Primary & Secondary (Shadow Rotation)

Structure: Two engineers are on-call simultaneously. The Primary receives the page first. If they do not acknowledge within a defined window (typically 5 minutes), the Secondary is automatically paged.

Pros: Reduces anxiety significantly. The Primary knows that sleeping through one alarm won't cause a customer-facing outage to go unaddressed. The Secondary also gets passive exposure to incidents, making them a better Primary when their turn comes.

Cons: Doubles the number of engineers in the rotation pool needed to maintain the same per-person frequency. The Secondary must also remain available, which means two engineers are restricted simultaneously.

Best Practice: Use Primary/Secondary as a baseline for any service that is customer-facing or revenue-critical. The cost of a second engineer on standby is far lower than the cost of a missed SEV1.

Interview Tip

Interviewers often ask: "How would you design an on-call rotation for a team of six engineers supporting a global service?" The strong answer covers: rotation topology (Primary/Secondary with Follow-the-Sun if budget allows), explicit handover rituals, compensation model, and a stated SLO for pages-per-shift. Mentioning that you'd measure alert noise ratio and set a target (e.g., < 2 actionable pages per shift) signals operational maturity.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free