On-Call Engineering: Rotations, Escalations, and Burnout Prevention
On-call management is the practice of organizing, scheduling, and supporting the engineers who respond to production incidents around the clock. It covers rotation design, escalation policies, alert routing, shift overrides, compensation, and the health metrics that reveal whether the whole system is sustainable. In plain terms, on-call management decides who gets woken up, how often, and at what human cost.
That cost is now well documented. According to Catchpoint's SRE Report 2025, roughly 70% of site reliability engineers say on-call stress has contributed to burnout and made them more likely to leave their jobs. The picture on alert quality is just as stark: the 2026 State of Production Reliability findings covered by APMdigest show that 77% of on-call teams receive at least 10 alerts per day, and 57% say fewer than 30% of those alerts are actionable.
On-call is the invisible tax of modern software operations. Every 24/7 service quietly bills its engineers in interrupted dinners, fragmented sleep, and weekend anxiety. Poorly managed rotations convert that tax into attrition; well-designed ones make reliability work sustainable and even rewarding. This guide walks through the full discipline — follow-the-sun rotations, severity-matched escalation timeouts, fair compensation, error-budget-gated paging, blameless reviews, and the cultural shift away from hero worship — so your team can keep services up without burning people down.
Why On-Call Management Is the Invisible Tax of Modern Software
Every always-on product carries an operational mortgage, and engineers pay the interest personally. Catchpoint's SRE Report 2025 found that site reliability engineers now spend a median of 30% of their week on operational work, up from 25% in 2024, and that 67% say they lack time for technical training because reactive duties crowd it out. The pager shapes careers, family schedules, and sleep long before it shows up on any budget line.
The personal toll is equally specific. PagerDuty's research on IT responder work-life balance found that 51.3% of IT professionals have their sleep or personal life interrupted more than 10 times per week by digital service disruptions, and 94% say always-on responsibilities affect their family life. Moreover, 23.1% report they are more likely to look for a new job because of it.
Left unmanaged, this tax compounds in three predictable ways:
- Attrition: experienced responders leave first, which concentrates load on those who remain and accelerates the spiral.
- Degraded judgment: exhausted engineers make slower, riskier decisions during the outages that matter most.
- Hidden cost: recruiting, onboarding, and lost delivery velocity dwarf the price of simply fixing the rotation.
The discipline that answers this problem grew out of Google's decision to run operations as an engineering problem rather than a staffing problem. Its founder summarized the philosophy in one sentence:
SRE is what happens when you ask a software engineer to design an operations team.
— Ben Treynor Sloss, Vice President of Engineering at Google, who founded the company's Site Reliability Engineering organization in 2003
Consequently, treating on-call management with the same rigor as system architecture is not a perk or a morale gesture. It is a reliability requirement, and the sections below break it into its component parts.
How Should You Design an On-Call Rotation?
Match the rotation model to your team's size, geography, and alert volume — rotation design is where practical on-call management starts, and no single model fits everyone. Google's Site Reliability Engineering book, published with O'Reilly Media in 2016, recommends a minimum of eight engineers for a single-site 24/7 rotation, or six engineers at each of two sites, so that nobody carries the pager more than roughly once a month. The same book frames why the duty deserves that level of design attention:
Being on-call is a critical duty that many operations and engineering teams must undertake in order to keep their services reliable and available.
— Andrea Spadaccini, Site Reliability Engineer at Google, in Chapter 11 of the Site Reliability Engineering book (2016)
What Is a Follow-the-Sun Rotation?
A follow-the-sun rotation is a scheduling model in which on-call responsibility passes between teams in different time zones so that every engineer responds only during local business hours. It eliminates overnight pages entirely, which is why globally distributed organizations treat it as the gold standard for burnout prevention.
However, follow-the-sun has hard prerequisites. The incident.io analysis of rotation models published in 2026 puts the realistic minimum at 9–15 engineers spread across at least three regions, plus disciplined written handoffs at every regional boundary. Small teams that fake geographic spread end up with the coordination overhead of distribution and none of the sleep benefits.
Weekly Versus Daily Rotations
Weekly rotations maximize context: the same responder tracks a flaky service across its whole arc, and everyone can plan life around a predictable calendar. The price is seven consecutive days of pager weight, which becomes brutal on noisy systems. Daily rotations flatten the load so nobody absorbs an entire bad week alone, but they multiply handoffs and therefore demand rigorous documentation between shifts.
Primary and Secondary Tiers for Incident Response
Mature incident response schedules always run at least two tiers. The primary responder takes the first page; the secondary is engaged automatically when the primary fails to acknowledge in time, and manually whenever an incident needs a second pair of hands. A useful refinement is making last week's primary this week's secondary, so the backup still carries fresh operational context.
| Rotation Model | Best For | Strengths | Risks |
|---|---|---|---|
| Weekly primary/secondary | Co-located teams of 6–12 engineers | High context retention; predictable planning | Seven consecutive days of pager stress |
| Daily rotation | Small teams of 3–5, or high-alert environments | Spreads load; nobody carries a bad week alone | Frequent handoffs lose incident context |
| Follow-the-sun | Distributed teams across 3+ time zones | Eliminates overnight pages entirely | Requires 9–15 engineers and strict handoff discipline |
| Shadow/buddy rotation | Onboarding new responders | Safe learning; no solo 3 a.m. baptism | Temporarily doubles staffing per shift |
The takeaway from the comparison is blunt: team size and time-zone spread, not personal preference, should pick your rotation model.
Shift Scheduling and Overrides: Planning for Holidays, Illness, and Real Life
An on-call schedule that ignores human life will be quietly sabotaged by the humans inside it. Overrides — temporary substitutions covering part or all of a shift — are the pressure valve, and they must be self-service. If swapping a shift requires a manager's sign-off or a support ticket, engineers will trade coverage informally in chat, and eventually a page will route to someone on a plane.
The incident.io on-call best practices guide published in 2026 highlights manual vacation handling as a leading cause of missed pages and recommends calendar-synced override tooling instead. Fairness also needs bookkeeping. Track who covered December 25 and January 1 each year, and rotate those slots deliberately rather than letting the same engineer absorb every holiday because they happen to have no children.
In addition, every shift boundary in a healthy on-call management program ships a written handoff covering:
- Active incidents with current status, severity, and explicit next steps.
- Silenced or suppressed alerts, each with an expiry date so silences never become permanent.
- Risky deploys, migrations, or feature-flag changes scheduled during the incoming shift.
- Direct links to the specific runbooks and dashboards that matter this week — never just "check the monitoring."
Finally, protect the shift after the shift. An engineer who handled a 3 a.m. incident needs a sanctioned path to start late, skip morning meetings, or take recovery time without negotiating for it. Predictable recovery rules cost far less than the mistakes tired engineers make the next afternoon.
Alert Routing and Escalation Policies: When Does a P2 Become a P1?
An escalation policy is the contract that guarantees every alert reaches a human who can act on it. The reference pattern, documented in PagerDuty's open-source incident response guide, runs three levels: primary responder, secondary responder, then a named engineering manager. Every escalation chain must terminate at a specific human being — never at an email alias or an empty step.
Timeouts should match severity, because generic 30-minute steps mean a revenue-stopping outage can sit untouched for 90 minutes. A sensible default matrix looks like this:
| Severity | Level 1: Primary | Level 2: Secondary | Level 3: Manager |
|---|---|---|---|
| P1 — critical, customer-facing outage | Paged immediately; 5-minute acknowledgment window | Paged after 5–15 minutes un-acknowledged | Paged after 15–30 minutes |
| P2 — degraded service, workaround exists | Paged; 10-minute acknowledgment window | Paged after 20 minutes | Notified after 30 minutes |
| P3 — low urgency | Ticket or digest queue, business hours only | Reviewed next business day | Not paged |
Un-acknowledged alerts climb the same ladder mechanically. A common standard: the platform tries the primary three times — push notification, then SMS, then a phone call — and if all three attempts on a P1 go un-acknowledged within five minutes, the secondary is woken; if the pattern repeats, the manager is. Nobody should ever have to wonder who gets called next.
Severity promotion deserves equally explicit rules, written down before anyone is tired. A P2 becomes a P1 when any of the following is true:
- Impact scope expands from a small subset of users to a majority, or reaches a customer with contractual uptime commitments.
- The incident stays unresolved past a defined duration threshold — commonly 60 minutes — while impact keeps growing.
- Error-budget burn rate crosses the fast-burn threshold for a customer-facing service-level objective.
- Data integrity, security exposure, or regulatory reporting obligations enter the picture.
Codifying these triggers removes the 2 a.m. judgment call. In practice, on-call management fails most often not at detection but at routing: the alert fired, and nobody empowered to fix the problem ever saw it.
On-Call Compensation and Fairness: Paying People for the Pager
Carrying a pager constrains an engineer's life even when it stays silent — no second glass of wine, no swim, no cinema with the phone off. Honest on-call management prices that constraint instead of treating availability as free. In Europe this is increasingly a legal question as well: the Court of Justice of the European Union held in its February 21, 2018 Ville de Nivelles v. Matzak ruling that sufficiently constrained standby time counts as working time.
Three compensation models dominate current industry guidance:
- Flat stipend: a fixed payment per on-call week — commonly $200–$500 in 2026 benchmarks — which is simple and predictable but blind to how bad the week actually was.
- Per-incident or per-hour response pay: compensates real disruption precisely, but can quietly reward alert noise when paired with weak alert hygiene.
- Time off in lieu: recovery half-days or full days after disrupted shifts, modeled into sprint capacity rather than granted as a favor.
Google's reliability organization blends these approaches. Engineers receive time-off-in-lieu or cash compensation for on-call work, deliberately capped, so the organization keeps a financial incentive to reduce paging load through engineering rather than buy silence with stipends — a design described in Chapter 11 of the same Site Reliability Engineering book cited above.
Should On-Call Be Voluntary or Mandatory?
For teams that own production services, on-call works best as a shared, expected responsibility with fair compensation — mandatory but humane. Purely voluntary rotations concentrate load on the conscientious few and quietly recreate hero culture. Purely conscripted rotations without pay, recovery time, or schedule input breed resentment and resignation letters. The defensible middle ground: everyone who ships code to production shares the rotation, everyone is compensated for it, and hardship exceptions for health or caregiving are handled privately and generously.
SLOs and Error Budgets: The Fastest Way to Reduce On-Call Pain
A service-level objective (SLO) is a measurable reliability target — for example, 99.9% of requests succeed over a rolling 30 days. The error budget is the permitted shortfall: the 0.1% of failures the business has explicitly agreed to tolerate. Together they turn the question "should this wake a human?" from an opinion into arithmetic, which makes them the single highest-leverage investment in on-call management.
The operating rule is blunt: if a condition is not burning the error budget, it should not page anyone. Google's Site Reliability Workbook chapter on on-call pairs this with a human ceiling — SRE teams cap operational work, including on-call response, at no more than 25% of an engineer's time, reserving at least 50% for the engineering projects that make next quarter quieter. Internal Google data puts the average cost of a production incident, including root-cause analysis and postmortem follow-up, at about six hours of focused effort, which is exactly why paging volume must stay low.
Migrating from cause-based paging to budget-based paging follows a repeatable sequence:
- Define service-level indicators that track what users actually experience — availability, latency, and correctness.
- Set SLO targets jointly with product owners, and publish them where everyone can see them.
- Alert on error-budget burn rate: page on fast burn, open a ticket on slow burn.
- Route everything else — CPU spikes, disk warnings, single-host failures — to dashboards and daytime queues.
- Review the budget monthly and renegotiate targets when they stop matching real user pain.
The payoff is a short, meaningful pager queue. Every page that survives the migration maps to demonstrable user impact and a budget number, so responders stop triaging noise and start trusting the pager again.
Blameless Post-Incident Review: Choosing Learning Over Blame
A blameless post-incident review reconstructs what happened and why, without punishing the people involved. The practice went mainstream after John Allspaw, then Senior Vice President of Technical Operations at Etsy, published "Blameless PostMortems and a Just Culture" on May 22, 2012. His core argument still defines the field:
An engineer who thinks they're going to be reprimanded is disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure. This lack of understanding of how the accident occurred all but guarantees that it will repeat.
— John Allspaw, then Senior Vice President of Technical Operations at Etsy, May 22, 2012
For on-call management specifically, the review meeting is where pain converts into prevention. Run it within a few days of the incident, while memory is fresh, and follow a fixed sequence:
- Reconstruct the timeline from logs, chat transcripts, and paging records — facts before interpretation.
- Identify contributing factors in the system: alerting gaps, runbook rot, deploy tooling, unclear ownership.
- Ask explicitly: "Should this have paged? Sooner? A different person?" and feed the answers back into routing rules.
- Assign follow-up actions to named owners with deadlines, and track them with the same rigor as product work.
Reviews that skip the fourth step are theater. The measure of a post-incident process is simple: does the same class of page recur, and does next quarter's on-call shift hurt less than this one did?
On-Call Health Metrics: How Do You Know Your On-Call Management Works?
You cannot fix a rotation you do not measure, and visibility is rarer than most leaders assume. The same PagerDuty work-life research cited earlier found that 72% of responders say their managers have little or no insight into when they are having a brutal on-call period. Measurement closes that gap and turns burnout prevention from anecdote into trend lines.
A practical on-call management scorecard tracks six numbers:
- Alert volume per shift, split into actionable versus noise — the single most predictive burnout indicator.
- False positive rate: the share of pages closed without action. PagerDuty's widely used benchmark holds that a team should see fewer than 40 alerts per week and that more than half should lead to real action.
- Mean time to acknowledge: a rising trend signals fatigue or coverage gaps long before anyone says the word "burnout."
- Off-hours and sleep-interrupting pages per person per month.
- Load distribution: one engineer catching three times the pages of their peers marks a hero problem, not a scheduling quirk.
- Override and swap frequency: a sudden spike in shift trades often precedes a resignation.
Review these numbers monthly in the team's operational meeting, not annually in an engagement survey. Some teams read the scorecard straight from their incident platform; others pull paging and ticket data into a lightweight internal dashboard — a use case where low-code platforms such as Informat let an SRE team ship a tailored on-call health app in days without diverting engineers from reliability work itself.
What Is a Healthy Number of Alerts Per On-Call Shift?
Google's reliability organization targets at most two incidents per 12-hour on-call shift, based on its finding that a typical incident consumes about six hours of response, remediation, and postmortem effort. Above that ceiling, engineers enter operational overload and decision quality drops measurably. If your shifts routinely exceed these bounds, the fix is engineering work on the alerting system and the service — not more stamina from the humans.
Choosing the Right On-Call Management Tool in 2026
The tooling market shifted sharply in the mid-2020s. Atlassian announced in March 2025 that Opsgenie will reach end of support on April 5, 2027, pushing thousands of teams into migration planning. PagerDuty remains the incumbent, while incident.io, FireHydrant, Rootly, and Grafana's alerting stack compete on tighter incident-workflow integration. Meanwhile, a 2026 DevOps.com analysis of AI-powered observability describes the newest layer: machine-learning triage that clusters, enriches, and suppresses alerts before they ever page a human.
Evaluate candidates against the rotation you actually run, not the demo:
- Escalation flexibility: per-severity timeouts, multi-tier chains, and round-robin within a tier.
- Override experience: self-service shift swaps from a phone in under a minute.
- Notification reliability: push, SMS, and voice fallbacks with per-user preferences.
- Analytics: alert volume, actionability, acknowledgment times, and per-person load out of the box.
- Integrations: observability sources in; chat, ticketing, and status pages out.
- Cost model: per-responder pricing quietly punishes the broad, humane rotations you want.
No paging vendor covers the workflows around the pager, however — compensation-time tracking, holiday fairness ledgers, post-incident action follow-up. Teams increasingly assemble those on Informat, an AI-powered low-code development platform, connecting paging data to the HR and project systems that dedicated on-call management tools ignore.
Can AI Triage Eliminate Alert Fatigue on Its Own?
No. AI-driven noise reduction compresses duplicate and flapping alerts impressively — PagerDuty's AIOps platform data shows up to 98% event-to-incident noise reduction for customers using its grouping features — but no model can decide what deserves to page in the first place. That remains an SLO and ownership question. Buy the compression, and still do the quarterly alert audit.
From Hero Culture to Sustainable On-Call Operations
Hero culture is the organizational habit of rewarding the engineer who firefights all night instead of the one whose service never pages. It feels like commitment; it is actually a systems failure with applause. A May 2026 essay on DevOps.com, "On-Call: The Silent Force Shaping Engineering Culture," argues that how a company practices on-call management reveals its real engineering values more accurately than any careers page.
Charity Majors, co-founder and Chief Technology Officer of the observability company Honeycomb, made the managerial responsibility explicit in her October 31, 2021 essay "On Call Shouldn't Suck": engineers should own their code in production, and managers own making that ownership humane. Both halves of the bargain matter, and only one of them is technical.
Sustainable operations look mundane by design. The markers are consistent across healthy teams:
- Runbooks exist, get tested, and are updated as post-incident actions — never held as tribal knowledge.
- Recurring toil is automated away; teams pursuing hyperautomation and AI workflow automation route repetitive remediation steps to machines and reserve humans for judgment.
- Quiet shifts are celebrated in retrospectives as loudly as heroic saves once were.
- Managers watch on-call health metrics and intervene on trends, not tragedies.
- New responders shadow before they solo, so nobody meets their first real page alone at 3 a.m.
The cultural test is what gets promoted. When a promotion packet cites "kept the pager quiet through two quarters of 40% traffic growth" as evidence of impact, the transition from hero culture to sustainable operations is real.
Conclusion: Making On-Call Management Sustainable in 2026
On-call management is a design problem, and design problems have solutions. The evidence base is consistent: burnout follows alert volume, unfair load, and absent recovery time — all of which yield to rotation design, severity-matched escalation policies, honest compensation, SLO-gated paging, and blameless reviews backed by tracked follow-through.
The playbook condenses to a short list:
- Size rotations so nobody carries the pager more than about one week in four, following Google's eight-engineer guidance.
- Escalate by severity, and end every chain at a named human being.
- Pay for availability, and budget recovery time after disrupted nights.
- Page only on error-budget burn; ticket everything else.
- Review incidents blamelessly, and track the fixes to completion.
- Watch alert volume, actionability, acknowledgment time, and load distribution every month.
Organizations that treat reliability operations as part of a broader modernization agenda — the same one driving AI-era enterprise digital transformation strategy — keep discovering that humane on-call management is not in tension with uptime. The teams that sleep are the teams that ship. Fix the rotation, gate the pager with SLOs, retire the heroes, and on-call stops being a tax on your engineers and becomes what it was always meant to be: an engineering discipline.