On-Call Roster & Fatigue Risk Planner
Plan sustainable on-call rotations, calculate fatigue risk, and optimize team coverage to prevent burnout
Formula
Shifts per Year = 52 weeks / (Team Size × Rotation Length weeks); Fatigue = f(Frequency, Duration, Incident Load)
On-call shifts per engineer per year is calculated by dividing 52 weeks by the product of team size and rotation length in weeks. Example: 6-person team with 1-week rotations = 52 / (6 × 1) = 8.7 weeks per engineer annually. Target is <6 weeks/year for sustainability. Fatigue score combines multiple factors: shift frequency (how often), duration (how long), and incident load (how many hours spent resolving issues). Additional factors include weekend coverage, backup availability, and team size adequacy. The formula works because it quantifies the burden distribution: larger teams with shorter rotations spread the load more evenly. However, absolute numbers don't capture context—2 hours/shift of complex debugging is more draining than 4 hours of routine tasks. Qualitative factors (incident severity, sleep disruption, documentation quality) matter as much as quantitative metrics. The formula provides baseline; team feedback and burnout signals provide context for adjustment.
Worked Examples
Example 1: SRE Team On-Call Planning
Problem:6-person SRE team, 1-week rotations, 3 incidents/week averaging 2 hours each. Weekend coverage required. Assess fatigue risk and optimize.
Solution:Current Setup: - Team: 6 engineers - Rotation: 1 week (7 days) - Shifts per person/year: 52 / 6 = 8.7 weeks - Incidents per shift: 3/week - Hours per shift: 3 × 2 = 6 hours - Avg hours/day: 6 / 7 = 0.86 hours Fatigue Analysis: - Frequency: 8.7 weeks/year (moderate; target <6) - Duration: 7 days (acceptable) - Load: 0.86 hours/day (low-moderate) - Weekend: Yes (+stress) - Fatigue Score: ~45 (Moderate risk) Problems: 1. Frequency slightly high (8.7 vs target 6) 2. Weekend coverage adds stress 3. No backup mentioned (single point of failure) Optimization Options: Option 1: Grow Team - Add 2 engineers → 8 total - Shifts per person: 52 / 8 = 6.5 weeks/year ✓ - Cost: $200K/year (2 × $100K) - Fatigue: Moderate → Low Option 2: Follow-the-Sun (if global team) - Split into 3 regions: Asia, EU,
Result:8.7 weeks/year per engineer (target <6) | Moderate fatigue risk | Add secondary rotation + reduce incidents
Frequently Asked Questions
What is on-call rotation?
On-call rotation is scheduled availability to respond to production incidents outside business hours. Engineers take turns being 'on-call'—carrying pager/phone, expected to respond within SLA (typically 15-30 min). Rotations are typically 1 week (168 hours). After rotation, next engineer takes over. On-call is necessary for 24/7 services but creates stress and disrupts personal time.
How many people do I need for sustainable on-call?
Minimum 4 for weekly rotations (each on-call 13 weeks/year). Healthy: 6-8 (6-9 weeks/year each). Excellent: 10+ (5 weeks/year each). Formula: Team size = 52 weeks / (target weeks per person × rotation length). Target <6 weeks/year per person to prevent burnout. Smaller teams (<4) experience unsustainable load; burnout and attrition result.
What is on-call fatigue and how do I prevent it?
On-call fatigue is burnout from sustained availability stress, sleep disruption, and unpredictability. Symptoms: anxiety, poor sleep, resentment, degraded incident response quality. Prevention: (1) Limit frequency (<6 weeks/year), (2) Short rotations (1 week, not 4), (3) Backup person (coverage for breaks), (4) Incident reduction (automation, better monitoring), (5) Compensation (time off, pay), (6) Handoff discipline (clear docs). Fatigue compounds—monitor team health.
Should on-call rotations be 1 week or 2+ weeks?
Shorter is generally better. 1-week rotations: Pro—shorter burden, frequent breaks. Con—more handoffs. 2-week rotations: Pro—fewer handoffs, deeper context. Con—sustained stress. Research shows 1-week preferred—ability to 'see the end' reduces stress. Exception: Low-incident services (<1/week) can do 2-week rotations. High-incident (>5/week) should do daily or follow-the-sun rotation.
What is follow-the-sun on-call?
Follow-the-sun distributes on-call across time zones: Asia team covers Asia hours, Europe covers Europe, US covers US. No one is on-call overnight. Requires global team (3+ regions). Benefits: Healthier work-life balance, faster response during business hours. Challenges: Handoff complexity, timezone communication, requires enough staff per region. Best for: Large teams (20+), global customers, high incident volume.
Should I pay for on-call time?
Yes. Options: (1) Stipend ($500-1,500/week), (2) Hourly rate for actual incidents, (3) Time-off comp (1 day off per week on-call), (4) Hybrid (stipend + incident pay). Paying signals respect and compensates for lifestyle disruption. Unpaid on-call = resentment and attrition, especially if frequent incidents. Check local labor laws—some jurisdictions require compensation.
How do I reduce on-call incidents?
Root cause analysis: Track incident types, identify patterns. Common fixes: (1) Better monitoring/alerts (reduce false positives), (2) Automation (auto-scaling, self-healing), (3) Runbooks (clear resolution steps reduce time), (4) Improved testing (prevent bugs reaching production), (5) Blameless postmortems (fix systems, not people). Goal: Reduce toil—incidents that can be automated. Google SRE target: <50% of time on toil.
What are signs of on-call burnout?
Individual: Anxiety before shifts, poor sleep, resentment, reduced incident response quality. Team: High attrition, sick leave spikes, decreased code quality, passive-aggressive behavior. Leading indicators: Incident volume increasing, mean-time-to-resolution growing, repeated handoff failures. If you see these: Immediately reduce load (add engineers, automate incidents, or temporarily reduce scope), debrief team, offer support.
Should I have primary and secondary on-call?
Yes, for high-impact services. Primary responds first. Secondary backs up if: primary unavailable (doctor appointment, sleep), incident requires expertise, or primary needs help. Reduces single-person pressure. Rotation: Primary week 1, Secondary week 2, Off weeks 3-N. Cost: 2× coverage means smaller team can't provide secondary. Minimum 6-8 engineers to support primary + secondary rotation sustainably.
How do I make on-call less painful?
Cultural: Blameless culture (no punishment for being paged), respect for personal time (avoid non-urgent pages), clear escalation (don't expect one person to solve everything). Technical: Good runbooks (step-by-step), fast rollback (reduce resolution time), observability (logs, metrics, traces readily available). Operational: Reasonable SLAs (not everything is P0), incident classification (only wake people for real emergencies), postmortems (prevent repeats). Compensation: Pay or time off.
Background & Theory
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
History
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