| Myth | Reality |
|---|---|
| On-call burnout is an individual resilience problem. | Burnout is a scheduling and staffing design problem; individuals cannot resilience their way out of a rotation with too few people or too many pages. |
| More alerts mean better coverage. | High alert volume with low signal quality is the single biggest predictor of on-call fatigue; fewer, better-tuned alerts protect people and systems better. |
| Being on-call should just be “part of the job,” unpaid. | Explicit on-call compensation, whether stipend or comp time, is now standard practice at mature engineering organizations and correlates with lower attrition. |
| A single rotation of the whole team is fair because everyone takes a turn. | Flat, whole-team rotations concentrate risk on whoever is on shift during a bad week; tiered and follow-the-sun models spread load more evenly across time zones and skill levels. |
| Escalation policies just need one backup person. | Effective escalation needs multiple tiers, secondary on-call, and a defined path to management, or a single missed page turns into a prolonged outage. |
Why On-Call Design Is a Reliability Problem, Not Just an HR Problem
Every incident management program eventually runs into the same wall: the software can be observable, the runbooks can be excellent, and the escalation policy can be technically correct, and the rotation can still burn people out. On-call is the point where reliability engineering meets human physiology, and most organizations get the human part wrong first. PagerDuty’s operational data shows the average on-call engineer receives roughly 50 alerts per week, yet only 2 to 5 percent of those alerts require actual human intervention, meaning the overwhelming majority of pages are noise, not signal, and that noise is what erodes trust in the pager and drains people faster than any real incident does.
The financial stakes make this worse, not better. Disruption costs are no longer trivial line items: PagerDuty’s 2026 State of AI-First Operations research found that some organizations lose more than one million dollars per hour during major unplanned outages, and more than two thirds of organizations lose over three hundred thousand dollars per hour. When leadership sees numbers like that, the instinct is often to over-page, over-escalate, and keep more people awake “just in case.” That instinct is exactly backward. Over-alerting degrades the very response capability that leadership is trying to protect, because a fatigued on-call engineer misses real signals inside a wall of false ones.
Sustainable on-call is therefore not a soft perk bolted onto an SLO program; it is core infrastructure. If your rotation design burns out your best engineers, your mean time to resolution degrades over time even if your tooling stays constant, because the people answering the pager arrive at 2 a.m. more exhausted, more error-prone, and more likely to leave the team entirely. Leadership teams that treat on-call design as an engineering investment, rather than a scheduling chore handed to whoever has time to build it, consistently see fewer repeat incidents and shorter time-to-resolution over a multi-quarter horizon, because the humans running the response are less depleted going into each shift.
The Anatomy of a Rotation That Does Not Burn People Out
Start With Pager Load, Not Headcount
Google’s Site Reliability Engineering book sets a useful anchor: target no more than roughly two incidents per on-call shift so responders have adequate time to actually follow up on each one, investigate root cause, and write a clean handoff. If your pager load routinely exceeds that, the fix is not “toughen up,” it is to reduce alert volume, add headcount to the rotation, or shorten shift length. Pager load is the single most important number in rotation design, and most teams have never actually measured it.
Layer the Rotation: Primary, Secondary, and Escalation
A single-person rotation with no fallback is fragile. The Google SRE model recommends a primary and secondary on-call structure, where the secondary exists specifically to catch pages the primary misses, whether from a missed notification, a dead phone battery, or a genuinely overwhelming incident that needs two responders. On top of that, a formal escalation path to a manager or incident commander should exist for anything that crosses a severity threshold or runs past a defined time limit, so no single engineer is left holding an outage alone for hours.
Match Shift Length to Cognitive Load, Not Calendar Convenience
Weekly rotations are the default because they are easy to schedule, not because they are optimal for the human nervous system. Shorter shifts, three or four days, reduce the cumulative fatigue of sleep disruption, particularly for services with a real chance of overnight pages. Longer shifts should only be used for genuinely quiet services with a low, well-understood page rate.
Figure 1: Layered escalation flow for a healthy on-call rotation
Alert fires against an SLO-based threshold, routes first to primary on-call, escalates automatically to secondary after a defined non-acknowledgment window, and escalates again to an incident commander or engineering manager if the incident crosses a severity or duration threshold, ensuring no single person absorbs an unbounded outage alone.
Follow-the-Sun: When Time Zones Do the Heavy Lifting
For organizations with genuinely distributed engineering teams across three or more time zones, follow-the-sun scheduling can remove overnight pages almost entirely. Each regional team owns coverage during its own daylight hours and hands off cleanly at shift boundary, so a team spanning the United States, Europe, and Asia-Pacific can, in practice, cut the overnight on-call burden per engineer dramatically, since no single region is ever covering the deep-night window for the whole system. The tradeoff is coordination overhead: handoffs need to be crisp, context needs to travel with the incident, and the team needs shared tooling and a shared incident management process, not three parallel ones. Follow-the-sun is not a fit for every team; a five-person startup with one time zone gains nothing from attempting it and should instead focus on tight pager-load limits and generous comp time.
| Rotation Model | Best Fit | Overnight Page Exposure | Coordination Overhead |
|---|---|---|---|
| Single flat rotation | Small teams, one time zone, low page volume | High for whoever is on shift | Low |
| Primary and secondary tiered rotation | Mid-size teams needing a safety net | Moderate, shared across two people | Moderate |
| Follow-the-sun regional rotation | Distributed teams across 3+ time zones | Low to near-zero overnight exposure | High, requires strong handoff discipline |
| Weighted rotation by seniority | Teams mixing new hires and veterans | Varies, tuned to reduce load on junior staff | Moderate |
Escalation Policies That Actually Work Under Pressure
An escalation policy is only as good as its worst day. Escalation design should assume the primary responder is unreachable, wrong, or overwhelmed, and route around that failure automatically rather than relying on a human remembering to call for help. That means defined acknowledgment windows, automatic secondary paging, and a documented threshold for looping in an incident commander. incident.io’s guidance on escalation policy design emphasizes keeping the policy simple enough that a half-asleep engineer can follow it without needing to think, because cognitive load during a 3 a.m. page is not the same as cognitive load during a calm afternoon planning meeting.
Escalation policies should also connect directly to the reliability signals your team already trusts. Pages tied to a real SLO burn rate carry more legitimacy than pages tied to arbitrary infrastructure thresholds, and responders learn to trust or distrust the pager based on how often it turns out to matter.
On-Call Compensation: The Part Most Companies Still Get Wrong
Unpaid on-call, treated as an unstated obligation of employment, is one of the most reliable predictors of quiet attrition on infrastructure and platform teams. Atlassian’s incident management guidance recommends modeling comp time directly into project planning rather than treating it as an afterthought, and many mature organizations now provide either a flat on-call stipend per rotation week or explicit compensatory time off after a heavy shift, sometimes a half day, sometimes a full day depending on how disruptive the shift was. The specific compensation model matters less than the existence of one: engineers who feel their disrupted sleep and personal time is explicitly recognized report substantially higher trust in their team’s on-call program.
Figure 2: Where on-call burnout actually comes from
Survey and vendor telemetry data consistently point to three compounding causes rather than one: excessive alert volume with low signal quality, insufficient rotation depth so the same few people absorb most pages, and absent or inconsistent compensation that makes the disruption feel unacknowledged by the organization.
Measuring the Human Side of Incident Management
Most teams instrument uptime obsessively and instrument on-call health almost never. A minimal human-side dashboard should track pages per shift per person, off-hours pages specifically, time-to-acknowledge trends over the last quarter, and voluntary attrition on rotation-carrying teams compared to teams that do not carry a pager. DORA’s 2025 State of DevOps research frames burnout, friction, and valuable work as equally important indicators of sustainable performance alongside traditional delivery metrics, which is a meaningful shift from treating burnout as a soft, unmeasured afterthought. Teams in DORA’s “foundational challenges” cluster show a pattern worth avoiding: high system stability purchased at the cost of high burnout and friction, which is not actually a sustainable trade, it is a delayed bill.
| Metric | What It Signals | Healthy Target Direction |
|---|---|---|
| Pages per on-call shift | Alert volume and tuning quality | At or below roughly two actionable incidents per shift |
| Percentage of pages requiring action | Signal-to-noise ratio of the alerting pipeline | Rising over time as noisy alerts get removed or tuned |
| Off-hours page rate | Sleep and personal-time disruption | Falling, especially for services with follow-the-sun coverage |
| Rotation-team attrition vs. non-rotation teams | Whether on-call load is driving people out | No meaningful gap between the two groups |
Common mistake
Building an escalation policy that assumes the primary responder will always acknowledge within minutes. Real people sleep through phones, lose signal, and get genuinely overwhelmed. Escalation policies without an automatic, time-boxed secondary path leave incidents unattended for hours precisely when speed matters most.
Common mistake
Rotating the entire team through on-call without adjusting shift length or depth as the team grows. A five-person rotation and a twenty-person rotation should not use the same schedule; more people in the rotation should translate directly into fewer on-call weeks per person per year, not just a larger shared burden.
Common mistake
Leaving on-call compensation as an unwritten, inconsistent norm that varies by manager. When compensation is not written into policy, it quietly becomes a source of resentment and a reason skilled engineers move to teams, or companies, that pay for the disruption explicitly.
What worked
Platform teams that tied every page to a documented, reviewed SLO burn-rate alert saw a substantial drop in nuisance pages within a single quarter, because any alert that did not clearly map to user-facing reliability risk was either tuned down or removed outright. Pairing that alert cleanup with a published, no-exceptions comp-time policy produced the largest measurable improvement in on-call satisfaction survey scores, more than any single tooling change.
Building a Rotation Design Checklist
Before publishing a new or revised on-call schedule, walk the design against a short set of questions: does pager load per shift stay near or below two actionable incidents; does every primary responder have a defined secondary with an automatic escalation window; is compensation, whether stipend or comp time, written down and applied consistently; does shift length match the actual overnight page risk for this specific service; and is there a documented incident-commander escalation path for anything that crosses a severity threshold. Teams that answer yes to all five tend to show up in postmortem reviews with far fewer “we paged the wrong person” or “nobody escalated in time” findings, because the structural gaps that cause those failures were closed before the incident ever happened.
It also helps to connect rotation design to the broader reliability practice on the team. Teams that already run chaos engineering exercises tend to discover escalation gaps in a controlled game day rather than during a real 3 a.m. outage, which is a far cheaper way to learn that your secondary on-call path silently points at someone who left the company six months ago.
A quarterly rotation health review is worth treating as a standing calendar item rather than an ad hoc exercise. Pull the pager-load, off-hours, and attrition metrics for the quarter, compare them against the previous quarter, and ask whether any single person absorbed a disproportionate share of pages. Rotation design tends to drift quietly as teams grow, services get added without corresponding rotation depth, or a well-meaning senior engineer volunteers to cover extra shifts and ends up doing so every quarter by default. A scheduled review catches that drift before it turns into a resignation letter.
Where AI and Automation Fit, Without Replacing the Human Safety Net
Modern AIOps tooling can meaningfully reduce pager load by correlating related alerts into a single incident, suppressing known-noisy signals automatically, and even triggering self-healing remediation for well-understood failure modes before a human is ever paged. This is a genuine and growing lever for reducing on-call burden, but it is not a substitute for the underlying rotation design. Automation that quietly suppresses an alert without a human ever confirming the suppression logic is sound just moves the failure mode from “too many pages” to “a real incident silently swallowed,” which is worse. The safest pattern is automation that reduces noise transparently and escalates to a human the moment confidence drops, keeping the layered escalation policy intact underneath the automation rather than replacing it. Teams adopting this kind of tooling should track suppression accuracy as its own metric, reviewed alongside pager load, so a quiet month reads as genuine improvement rather than as alerts being swallowed unnoticed.
- On-call rotation
- A recurring schedule assigning responsibility for responding to production alerts to a specific engineer or team for a defined shift window.
- Pager load
- The number of actionable incidents a given on-call responder receives during a single shift, used as a core measure of rotation sustainability.
- Escalation policy
- The documented, automated sequence of who gets notified next, and after how long, if the current responder does not acknowledge an alert.
- Follow-the-sun
- A rotation model where on-call responsibility passes between regional teams so each team covers only its own local daylight hours.
- Incident commander
- The designated person who coordinates response, communication, and decision-making during a significant incident, distinct from the engineer actively fixing the issue.
- Alert fatigue
- The desensitization and slowed response that results from receiving a high volume of low-value or false-positive alerts over time.
- Comp time
- Compensatory time off granted to an engineer after a disruptive on-call shift, used as an alternative or supplement to direct stipend pay.
- Burn rate
- The rate at which a service is consuming its error budget relative to its SLO target, often used as the trigger condition for a page.
Key Takeaways
- Target roughly two actionable incidents per on-call shift; exceeding that consistently signals a staffing or alert-tuning problem, not a toughness problem.
- Layer every rotation with a primary, a secondary, and a defined escalation path to an incident commander so no single person absorbs an unbounded outage alone.
- Follow-the-sun scheduling can sharply cut overnight page exposure for teams genuinely distributed across three or more time zones, but adds real handoff coordination cost.
- Written, consistently applied on-call compensation, whether stipend or comp time, correlates strongly with lower attrition on rotation-carrying teams.
- Tie alerts to real SLO burn-rate signals rather than arbitrary infrastructure thresholds so the pager earns and keeps the team’s trust.
- Measure the human side of on-call, pages per shift, off-hours rate, and rotation-team attrition, with the same rigor applied to uptime metrics.
- Use automation and AIOps correlation to cut noise transparently, but keep the underlying escalation policy intact rather than letting automation quietly replace human judgment.
FAQs
How many people should be in a healthy on-call rotation?
There is no universal number, but as a rough guide, most teams aim for enough people that no single engineer is on-call more than one week in four to six. If pager load or rotation frequency exceeds comfortable limits, add headcount to the rotation or reduce alert volume before adding more people to the schedule.
What is a reasonable number of pages per on-call shift?
Google’s SRE guidance targets roughly two actionable incidents per shift as a ceiling, since that leaves enough time to properly investigate and follow up on each one. Consistently higher volumes usually indicate noisy, poorly tuned alerting rather than genuinely higher operational risk.
Should on-call engineers be paid extra for carrying the pager?
Most mature engineering organizations now provide either a stipend, comp time, or both for on-call weeks, separate from base salary. Leaving compensation unwritten and inconsistent is one of the more reliable predictors of quiet attrition on infrastructure and platform teams.
What is follow-the-sun on-call and when does it make sense?
Follow-the-sun distributes coverage across regional teams so each team only covers its own local daytime hours, handing off at shift boundaries. It meaningfully reduces overnight pages for organizations genuinely distributed across three or more time zones, but adds coordination overhead that is not worth it for small, single-time-zone teams.
How is escalation policy different from an on-call rotation?
The rotation defines who is responsible for a given shift; the escalation policy defines what happens automatically if that person does not respond in time. A rotation without a solid escalation policy behind it leaves incidents unattended whenever the primary responder is unreachable.
Can automation reduce on-call burnout without hiding real incidents?
Yes, when automation correlates related alerts, suppresses known-noisy signals transparently, and escalates to a human the moment confidence drops. The risk appears only when suppression logic runs silently without any human ever validating that it is correctly distinguishing noise from a genuine problem.
How do SLOs improve on-call rather than just measuring uptime?
Alerts tied to real SLO burn-rate thresholds signal genuine user-facing risk rather than arbitrary infrastructure noise, which means responders learn to trust the pager instead of dreading it. Teams that connect on-call alerting to SLOs directly report fewer nuisance pages and more confidence that a page means something real.
What is the single biggest predictor of on-call burnout?
Alert volume with low signal quality consistently ranks as the top driver, since responders receiving dozens of low-value pages a week lose trust in the system and suffer cumulative fatigue even when few incidents are truly severe. Fixing signal-to-noise ratio typically produces bigger burnout improvements than adding more people to the rotation.
References
- Google SRE Book, “Being On-Call”: https://sre.google/sre-book/being-on-call/
- Google SRE Workbook, “On-Call”: https://sre.google/workbook/on-call/
- PagerDuty, “2026 State of AI-First Operations”: https://www.pagerduty.com/newsroom/2026-state-of-ai-first-operations/
- PagerDuty, “Mental Health Awareness Month: How to Build Sustainable On-Call”: https://www.pagerduty.com/blog/insights/mental-health-awareness-month-how-to-build-sustainable-on-call/
- Atlassian Incident Management Handbook, “Setting up a policy for paying on-call teams”: https://www.atlassian.com/incident-management/on-call/on-call-pay
- Atlassian Incident Management, “A better approach to on-call scheduling”: https://www.atlassian.com/incident-management/on-call/on-call-schedules
- incident.io, “Escalation policy best practices”: https://incident.io/blog/escalation-policy-best-practices
- DORA, “State of DevOps Report”: https://dora.dev/research/2024/dora-report/
