On-call Sustainability
Recognizing burnout signals, the SRE Workbook's sustainable on-call framework, and the metrics that protect engineer health.
Overview
Burnout is structural
On-call burnout is the leading cause of SRE attrition. Engineers who started with passion become apathetic, quality drops, and recruiting becomes a treadmill.
The fix is structural. "Be a more resilient engineer" is not the answer.
> [!IMPORTANT] Sustainable on-call needs leadership to fund page reduction. The 50% engineering time the SRE Book mandates exists for exactly this.
The sustainable-on-call framework
The SRE Workbook's On-Call chapter: "The on-call rotation should be sustainable, allowing for time outside of work to recover and recharge."
- Time on incident response — Under 25% of work time, a rough Google guideline
- Pages — Under 2 per 12-hour shift
- Rotation — 1-in-N where N is comfortable for the team, such as 1-in-6 weeks
Burnout signals
- Pager anxiety even when off-shift — Page volume rising month over month with no plan
- "I dread the rotation" — New SREs leaving within 6-12 months
- Worse response quality: skipped investigation, "restart the service" by default — Postmortem action items not shipping for lack of engineering time
- Less project output during on-call weeks — Senior engineers stop volunteering
- Poor sleep, insomnia, anxiety — Harder recruiting: "I heard your on-call is brutal"
- "I'd quit if I had to keep doing this"
Mitigation tactics
- 1. Reduce page volume — Kill noisy alerts; turn non-actionable alerts into dashboards; multi-window multi-burn-rate to stop flapping; ship postmortem follow-ups
- 2. Rotation depth — At least 4-6 weeks between shifts, more if volume is high: 1-in-6 with 5 pages per shift is ~1 unscheduled page a day of life; time off after heavy shifts; mental-health days
- 3. Tools and runbooks — Better runbooks shorten incidents; better dashboards cut diagnosis load; better automation means fewer interruptions
- 4. Compensation — Hourly, per-page or stipend pay; time in lieu as extra PTO; visible recognition
- 5. Cultural support — Manager check-in mid-rotation; retrospective after each shift; public acknowledgment of hard shifts; "It's OK to escalate"
> [!TIP] The 80% rule: 80% of pages come from 20% of services. Target the noisy services with automation, better SLO design and dependency hardening.
What leadership must do
- Measure — Track page volume as a team-health metric
- Fund — Allocate engineering time to the top sources
- Endorse — Back killing noisy alerts
- Reward — Recognize postmortem action-item completion
- Listen — Hear engineer feedback in 1:1s
The escalation valve
When on-call becomes painful, the team must be able to say no: refuse new services, push back on the roadmap, or hand back ownership. Without this valve, on-call gets worse forever.
> [!IMPORTANT] The SRE and dev contract inverts the incentive: dev wants to fix the service instead of pushing it onto SRE.
Key concepts
- < 25% time on incidents
- Google SRE Book guideline. More = unsustainable. Track over a quarter.
- 80% of pages from 20% of services
- Page volume usually concentrated. Target the noisy 20% for engineering investment.
- Burnout signals (individual)
- Pager anxiety, response quality drops, skipping investigation, considering resignation.
- Burnout signals (team)
- Increasing page volume, attrition < 1 year, postmortem items not shipping, hiring difficulty.
- Engineering time investment
- 50% engineering time = the resource for page-reduction work. Without it, on-call decays.
- Hand-back valve
- SRE can refuse services that don't meet quality bar. Inverts incentive: dev wants to fix.
When to use it
- Quarterly team-health reviews — measure page volume and trends
- On-call retrospectives — what made this shift hard?
- 1:1 with team members — pager-load discussion as standard agenda item
- Hiring conversations — communicate on-call expectations honestly
Interview questions
- How do you reduce on-call burden when it's already high?
- How do you have an honest on-call conversation with a candidate?
- When should an SRE team REFUSE to take on a new service?
Sign up free to read the full topic
More SRE topics
Start free on Cariara · Coding problems · System design studio