On-Call Rotation: Design, Fairness, Burnout Prevention

On-call is the tax engineers pay for owning production. It's necessary — software nobody owns at 3 AM stays broken. But badly designed rotations burn out engineers, drive attrition, and reduce response quality when it matters.

The design dimensions

Rotation size

• Sweet spot 5 to 8 engineers
• Smaller (3) is burnout; every 3 weeks on-call
• Larger (15+) loses context; engineers forget systems between shifts

Shift length

• 1 week for primary is standard
• Shorter shifts have frequent transitions; harder to follow long incidents
• Longer shifts have heavy personal impact

Primary plus secondary

• Primary responds to pages within 15 minutes
• Secondary escalates if primary doesn't ack
• Secondary is lighter duty; checks in only if paged

Follow-the-sun

• If teams are in US, EU, India: split shifts by timezone so no one handles night pages
• Only works with distributed teams across 3+ regions
• US-only teams have to handle nights; design compensation accordingly

Page budget

• Target fewer than 2 pages per shift
• More than 5 pages per shift is a broken service or broken alerts
• Track weekly; drives alert-tuning investment

Compensation

• On-call is work; compensate with comp days, stipends, or PTO after heavy shifts
• Without compensation, senior engineers leave; juniors burn out silently
• Market rate around $500 per week for on-call stipend at many tech companies

Runbooks mandatory

• Every alert links to a runbook
• On-call shouldn't reinvent investigation at 3 AM
• Review and update runbooks during retrospectives; outdated runbook is worse than none

The escalation chain

• Primary: 15 minutes to ack
• If no response: secondary paged
• If no response: engineering manager
• If no response: VP engineering
• Clear timeout at each level; no ambiguity about who responds

Onboarding new engineers

• Don't put juniors on primary immediately
• Week 1-2: shadow current on-call, observe alerts and response
• Week 3-4: pair on-call with experienced engineer
• Week 5+: primary with experienced secondary
• Release to full rotation only when they're comfortable, not on schedule

Post-rotation retrospective

• End of each rotation, review what paged
• Which alerts were noise? Which runbooks were missing or incorrect?
• Any service needs more attention? Any burnout signals?
• Action items go to ticket tracker; close the loop before next rotation

Common anti-patterns

• Team size less than 4 covering on-call; sustainability impossible
• No compensation; retention killer
• Ignoring alert fatigue; real pages get missed when 80% are noise
• Outdated runbooks wasting on-call time at 3 AM
• Primary unresponsive because of meetings; rotation design is broken
• Junior-only or senior-only rotations; both are bad
• Hiding page counts from leadership; normalizes broken state

Chaos drills build confidence

• Game days simulate incidents without real impact
• On-call engineers practice response, discover runbook gaps, build tool familiarity
• Quarterly practice beats first-time-during-real-incident

Physical health matters

• Sleep disruption, stress, always-on-phone anxiety are real
• HR should monitor on-call teams for burnout signals
• Anonymous surveys surface issues before attrition

The strategic answer

• On-call is a first-class design problem
• Rotation size 5 to 8, 1-week shifts, primary plus secondary
• Fewer than 2 pages per shift as target; invest in alert hygiene
• Compensate on-call time honestly
• Runbooks are mandatory; retrospectives close the loop
• Onboard juniors gradually; chaos drills build confidence
• Track page load transparently; normalize improvement