On-Call Coverage Roster & Fatigue Risk Planner

On-call coverage roster planning balances incident response availability with engineer wellbeing, using rotation frequency, shift duration, and incident load to prevent burnout while maintaining service reliability. ## Concept Overview Services requiring 24/7 availability need on-call coverage: designated engineers ready to respond to production incidents anytime. The tension: one person can't be on-call forever (burnout), but too many handoffs create context loss. The optimization problem: distribute on-call burden across team to prevent individual fatigue while maintaining incident response quality. Fatigue comes from three sources: (1) Frequency (how often you're on-call), (2) Duration (how long each shift), (3) Load (how many incidents). An engineer on-call 1 week every 6 weeks with 2 incidents is manageable. Same person on-call 1 week every 3 weeks with 8 incidents experiences burnout. The cumulative stress of interrupted sleep, constant vigilance, and unpredictability erodes wellbeing. Sustainable on-call requires: adequate team size (more engineers = fewer shifts each), reasonable expectations (not all incidents are true emergencies), incident reduction (automation, better testing), and compensation (acknowledging the burden). Treating on-call as extractable free resource leads to attrition, which makes the problem worse (fewer engineers = more load per person = death spiral). ## Key Variables & Intuition • **Team Size** — More engineers = fewer shifts per person = lower fatigue • **Rotation Length** — Shorter shifts (1 week) preferred over long (4 weeks) for stress management • **Incident Frequency** — Fewer incidents = less stressful shifts • **Incident Duration** — 30-minute fixes less disruptive than 4-hour emergencies • **Weekend Coverage** — Adds stress; weekends are valued personal time • **Backup Rotation** — Secondary on-call reduces pressure on primary • **Compensation** — Pay or time-off acknowledges burden ## Assumptions • Incidents are randomly distributed (burst periods create higher stress) • All team members are equally capable (expertise gaps complicate rotation) • Response SLA is consistent (15-30 min typical; faster = more stressful) • Incidents require human intelligence (automatable incidents should be automated) • Team size is stable (attrition disrupts rotation and increases load) ## Limitations & Edge Cases • **Expertise requirements** — Not all engineers can handle all incidents; may need tiered rotation • **Global distribution** — Teams across time zones enable follow-the-sun (no overnight pages) • **Incident bursts** — Black Friday, product launches create temporary spike • **False positives** — Noisy alerts page people unnecessarily (alert fatigue) • **Vacation coverage** — On-call during vacation is controversial; some companies prohibit, others compensate heavily **Scenario:** A 4-person team has weekly rotation. Each engineer is on-call 13 weeks/year. Incidents average 5/week × 3 hours each = 15 hours/shift. One engineer quits (attrition). Now 3-person team, 17 weeks/year each. Load increases: 17 weeks × 15 hours = 255 hours/year vs. previous 195. Remaining engineers burn out. Another quits. Now 2-person team, 26 weeks/year each. Death spiral. Prevention: Maintain minimum team size (6+) with buffer for attrition, invest in incident reduction, compensate fairly. ## Interpretation Guide **Shifts per Engineer per Year:** - <6 weeks: Sustainable; healthy work-life balance - 6-10 weeks: Acceptable with good compensation - 10-15 weeks: High burden; monitor for fatigue - 15-20 weeks: Unsustainable; attrition risk - >20 weeks: Critical; immediate intervention needed **Fatigue Score:** - 0-30: Low risk (sustainable) - 30-50: Moderate risk (monitor team health) - 50-70: High risk (implement mitigations immediately) - 70-100: Critical risk (burnout imminent) **Avg Hours per Day on Shift:** - <1 hour: Light load - 1-2 hours: Moderate (manageable) - 2-3 hours: Heavy (stressful) - >3 hours: Extreme (unsustainable) ## Practical Tips • **Limit to 6 weeks/year per person** — Target maximum; reduces burnout • **Use 1-week rotations** — Shorter shifts reduce sustained stress vs. 2-4 week rotations • **Implement secondary on-call** — Backup person provides coverage and reduces pressure • **Compensate fairly** — Stipend, time off, or hourly pay for incidents • **Invest in incident reduction** — Every automated incident = less on-call burden • **Handoff rituals** — Outgoing person briefs incoming on active issues and ongoing investigations • **Respect boundaries** — Don't page for non-urgent issues overnight; can wait until morning ## Common Mistakes • **Too-small team** — 3-4 person rotation creates unsustainable load (13+ weeks/year each) • **Too-long rotations** — 4-week shifts feel endless; 1-week provides "light at end of tunnel" • **No compensation** — Unpaid on-call breeds resentment and attrition • **Noisy alerts** — False positives train people to ignore pages (alert fatigue → missed real incidents) • **No backup** — Primary on-call with no secondary = no breaks, high stress • **Ignoring fatigue** — "They'll tough it out" leads to burnout and quitting ## When NOT to Use Traditional On-Call • **Low-value services** — Not everything needs 24/7 response; let non-critical systems wait until morning • **Automatable incidents** — If 80% of pages can be automated, do that instead of rotation • **Follow-the-sun feasible** — Global team means daytime-only coverage (better for health) • **Vendor SLA sufficient** — Managed services (AWS, Datadog) may provide response; don't duplicate

On-call rotation management evolved from informal pager duty to sophisticated fatigue-aware scheduling as always-on services made 24/7 availability critical and burnout became recognized operational risk. ## Origins & Why It Emerged Early computing (mainframes, 1960s-1980s) had scheduled maintenance windows. Systems went offline overnight or weekends. Operators had shifts, but no expectation of instant response. If something broke at 2 AM, it waited until morning. The internet changed this. Web services (1990s-2000s) ran 24/7. E-commerce couldn't have "closed for maintenance" downtime. The pager emerged: someone must be available always. Early on-call was ad-hoc: senior engineer carried pager, got woken up, fixed issue. No rotation—same person always on-call. Burnout was inevitable. The question became: how do we maintain 24/7 availability without destroying engineers' lives? Rotation systems emerged: share the burden, limit individual exposure. But poor rotation design just distributed burnout evenly rather than preventing it. The field learned: sustainable on-call requires thoughtful design. ## How It Evolved in Practice 2000s: Startups had hero culture. The founder or lead engineer was "always on-call." This worked until growth required scale. First rotations were simple: weekly rotation among 3-4 engineers. Each person on-call 13-17 weeks/year—unsustainable. Attrition followed. Mid-2000s: Organizations learned: larger rotation pools reduce individual burden. Teams grew to 6-8, reducing shifts to 6-9 weeks/year. But another problem emerged: not all engineers had equal expertise. Junior engineers got paged, escalated to seniors, who ended up working anyway. Tiered on-call emerged: L1 (junior), L2 (senior), L3 (architect). 2010s: PagerDuty (2009) and similar platforms automated incident routing and escalation. Google SRE book (2016) codified best practices: limit on-call to <50% of time, invest in reducing toil, blameless postmortems. Follow-the-sun rotations (global teams) eliminated overnight pages. Compensation (pay or time off) became standard. 2020s: Burnout awareness increased. Companies realized: unsustainable on-call leads to attrition, which increases load on remaining engineers (death spiral). Modern approach: treat on-call as operational cost requiring investment (automation, hiring, tooling) rather than free resource extractable from engineers. ## Modern Usage Today Modern on-call combines: rotation scheduling (PagerDuty, Opsgenie), incident management (automated triage, runbooks), and compensation (stipends, time off). Teams target <6 weeks/year per engineer with 1-week rotations. Incidents are categorized: P0 (wake anyone), P1 (can wait until morning), P2+ (next business day). Observability (logs, metrics, traces) reduces diagnosis time. The trend is toward eliminating unnecessary on-call through better reliability (SLOs, error budgets) and automation (self-healing systems). Google SRE principle: if you're paged, it should require human intelligence—automatable incidents shouldn't page humans. ## Common Misconceptions Historically • **"On-call is free"** — Unseen cost: burnout → attrition → hiring/training → even more load • **"More pages = healthy monitoring"** — Excessive alerts train engineers to ignore pages (alert fatigue) • **"Anyone can be on-call"** — Requires training, runbooks, and expertise; throwing junior engineers into rotation without preparation is cruel • **"Overnight pages are acceptable"** — Sleep disruption has compounding health effects; minimize or compensate