On-Call Burnout Risk Scheduler
Analyze on-call rotation sustainability. Calculate burnout risk based on team size, incident frequency, and after-hours load.
Formula
Burnout Risk = (Interruption Score × 0.35) + (Frequency Score × 0.25) + (Intensity Score × 0.25) + (Team Load Score × 0.15)
The formula weights four factors affecting on-call sustainability. Interruption score (35%) reflects after-hours incidents—the biggest burnout driver. Frequency (25%) measures how often engineers are on-call. Intensity (25%) combines incident volume and resolution time. Team load (15%) penalizes understaffed teams. This weighting comes from SRE research showing sleep disruption has outsized impact on burnout. The formula produces a 1-10 risk score where higher means more urgent intervention is needed.
Worked Examples
Example 1: Healthy SRE Team
Problem:8 engineers, 7-day rotation, 3 incidents/week average, 1.5 hours resolution, 30% after-hours.
Solution:45 days on-call/year per person. ~2 incidents per shift. Low after-hours interruption. Burnout risk: 3.2/10 (Low).
Result:3.2/10 risk | Sustainable schedule | Good team size
Example 2: Understaffed Startup
Problem:3 engineers, 7-day rotation, 8 incidents/week, 2 hours resolution, 50% after-hours.
Solution:121 days on-call/year per person (33%!). ~8 incidents per shift with 4 after-hours. Burnout risk: 8.1/10 (High).
Result:8.1/10 risk | Unsustainable | Must grow team or reduce incidents
Example 3: High-Volume Platform
Problem:6 engineers, 7-day rotation, 15 incidents/week, 1 hour resolution, 40% after-hours.
Solution:60 days on-call/year. 15 incidents per shift is very high. Even with fast resolution, volume creates stress. Burnout risk: 6.5/10 (Medium).
Result:6.5/10 risk | Incident volume too high | Reliability investment needed
Frequently Asked Questions
What is on-call burnout?
On-call burnout is exhaustion from sustained incident response duties. Symptoms include fatigue, decreased performance, cynicism about work, and eventually turnover. It's caused by sleep interruption, unpredictability, and chronic stress.
How many engineers for sustainable on-call?
Minimum 4-5 for basic coverage. 6-8 is healthier. Fewer means each person is on-call too often. The SRE rule of thumb: no one should be on-call more than 25% of the time (one week per month).
What's a good rotation length?
7 days (weekly) is common and works well. Shorter rotations (3-4 days) reduce individual burden but increase handoff overhead. Longer rotations (2 weeks) cause more fatigue. Match to your incident patterns.
How do after-hours incidents affect burnout?
After-hours pages are 2-3x more impactful on burnout than daytime. They interrupt sleep, disrupt family time, and prevent true rest. Reducing after-hours incidents should be a priority—often through better architecture and automation.
What's an acceptable incident rate?
Varies by service maturity. Target: under 2 actionable pages per on-call shift. More than 5 per week indicates reliability problems. Google SRE aims for pages to be rare and meaningful.
How do I reduce on-call burden?
Options: grow the team, improve reliability (fewer incidents), automate responses, shift incidents to business hours through architecture, implement follow-the-sun (global team), and ensure adequate compensation.
Should on-call be compensated separately?
Best practice: yes. Flat stipend for being on-call plus additional pay for actual incidents, especially after-hours. Compensation acknowledges the burden and improves retention.
How do I detect early burnout signs?
Watch for: slower response times, more incidents escalated, decreased participation in improvements, increased sick days, cynical comments, and requests to transfer teams. Address proactively.
What about follow-the-sun on-call?
If you have global teams, follow-the-sun keeps everyone in business hours. This dramatically reduces after-hours burden. Requires good handoff processes and distributed expertise.
How do I make on-call fairer?
Equal rotation, compensate for intensity differences, allow shift swaps, account for PTO/holidays, recognize that some services are harder, and involve the team in scheduling decisions.
Background & Theory
On-call burnout risk analysis evaluates the sustainability of incident response duties based on team size, incident patterns, and rotation structure.
Concept Overview
On-call burnout risk depends on frequency (how often you're on-call), intensity (how demanding each shift is), and interruption quality (when incidents occur). A sustainable rotation balances these factors.
The key insight: burnout is cumulative. A single intense week is manageable. Months of sleep interruption create lasting damage. Risk assessment should consider the annual picture, not just individual rotations.
Key Variables & Intuition
- Team size — More engineers = less frequent rotation
- Rotation length — Days per on-call shift
- Incident frequency — Pages per week on average
- Resolution time — Hours per incident
- After-hours % — Incidents outside business hours
Assumptions
- Incidents are distributed somewhat evenly
- All team members participate equally
- Resolution times are consistent
- Current patterns continue
Limitations & Edge Cases
- Incident clustering — Some weeks are much worse than average
- Skill variation — Some engineers handle incidents faster
- Secondary on-call — May be less intense but still disruptive
- Emotional labor — High-stakes incidents are more draining
Scenario: A team has "only" 3 incidents per week, but they're all critical customer-facing outages requiring 4+ hours to resolve. The numbers look manageable, but the intensity and stakes create significant burnout risk.
Interpretation Guide
Burnout Risk Score:
- Below 4: Low — sustainable long-term
- 4-6: Medium — monitor and improve
- Above 6: High — urgent intervention needed
Red Flags:
- On-call more than 25% of time
- More than 5 incidents per shift
- More than 50% after-hours
- Team smaller than 5
Practical Tips
- Target 6+ engineers — Minimum for sustainable rotation
- Weekly rotations — Balance continuity and rest
- Measure and reduce after-hours — Biggest burnout factor
- Compensate fairly — Acknowledge the burden
- Allow shift swaps — Flexibility reduces resentment
- Invest in reliability — Fewer incidents = less on-call burden
Common Mistakes
- Too small a team — Everyone on-call constantly
- Ignoring alert quality — Noise causes fatigue
- No escalation path — One person bears all burden
- No compensation — Creates resentment
- Heroics culture — Normalizes unsustainability
- Ignoring feedback — Team knows when it's too much
When NOT to Use
- Fully automated services — May not need human on-call
- Business hours only services — Different model applies
- External SOC/NOC — Outsourced response
History
On-call practices evolved from NOC operations through DevOps transformation to modern SRE approaches focused on sustainability.
Origins & Why It Emerged
Traditional IT had dedicated Network Operations Centers (NOCs). Operators monitored systems 24/7 in shifts. The separation between ops (who responded) and dev (who built) created friction and slow fixes.
DevOps (2008+) introduced "you build it, you run it." Engineers who wrote code also supported it in production. This improved accountability but shifted incident response burden to development teams.
Site Reliability Engineering (SRE), formalized by Google, created frameworks for sustainable on-call. SRE recognized that unsustainable on-call leads to burnout and attrition. Practices emerged to balance reliability with quality of life.
How It Evolved in Practice
Early on-call was often brutal. Small teams meant constant coverage. Pagers went off constantly for non-actionable alerts. Sleep deprivation was normalized.
Mature practices developed. Alert hygiene reduced noise. Runbooks enabled faster resolution. Rotation schedules balanced load. Compensation acknowledged the burden.
Tooling improved. PagerDuty, OpsGenie, and similar services enabled sophisticated scheduling, escalation, and analytics. Teams could measure and optimize on-call health.
Modern Usage Today
Modern on-call emphasizes sustainability. Error budgets limit toil. Alert quality is measured. On-call is part of team health metrics. Engineers have input on scheduling.
Remote work added complexity. Global distribution enables follow-the-sun. But isolation makes incidents lonelier. Tools adapted for distributed incident response.
Common Misconceptions Historically
- On-call is unavoidable suffering — It can be sustainable with proper practices and team size
- More alerts = better monitoring — Alert fatigue causes worse outcomes; fewer, actionable alerts are better
- Everyone should be on-call — Some roles don't make sense; specialize appropriately
- Compensation solves burnout — Money helps but doesn't fix unsustainable load
- Heroics are good — Individual heroics indicate systemic problems to fix