On-Call Burnout: What the Data Says (2026)

Key Takeaways

• Google's SRE guidance sets a hard ceiling on incidents per shift. The SRE Workbook states: "We target a maximum of two incidents per on-call shift." The widely repeated "two to three incidents" is a paraphrase; the primary source says two.
• An incident is a problem, not an alert. The same chapter defines it precisely: "One 'incident' is defined as one 'problem,' no matter how many alerts have been fired for the same 'problem.'" A single problem that fires forty pages is still one incident, which is why alert correlation, not alert volume, is the load that matters.
• Operational work is capped at 50 percent. The SRE Book states: "We cap the amount of time SREs spend on purely operational work at 50%," with "no more than 25% can be spent on-call." The cap exists so engineering does not collapse into firefighting.
• Rotations have a minimum size for a reason. Google's guidance: "the minimum number of engineers needed for on-call duty from a single-site team is eight." Below that, individuals carry unsustainable frequency.
• Stress physically degrades incident decisions. The SRE Book is explicit: stress hormones "can impair cognitive functions and cause suboptimal decision making," and under pressure "the more deliberate cognitive approach is typically subsumed by unreflective and unconsidered (but immediate) action."
• Alert fatigue traces to signal-to-noise. The Workbook: "a low signal-to-noise ratio raises the risk for on-call engineers to develop alert fatigue." The fix is fewer false pages, not tougher engineers.
• Incidents already carry a measured human cost. PagerDuty's 2026 survey of 1,000 leaders found respondents citing incidents as "contributing to developer burnout (42%)" and "reducing productivity (48%)."

On-call burnout is the chronic exhaustion, cognitive impairment, and disengagement that builds when the volume, unpredictability, and stress of incident response exceed what a rotation is sized to absorb. It is not a personal failing, and Google's own SRE practice treats it as an engineering problem with numeric limits: a cap on incidents per shift, a cap on operational time, and a floor on rotation size. This post works from those primary sources, then covers where AI investigation genuinely helps and where it does not.

The temptation is to treat burnout as a wellness topic. The more useful framing, and the one Google's SRE organisation actually uses, is that burnout is what happens when a rotation is loaded past its design limits. The limits are published. Most teams have simply never checked their own numbers against them.

How many incidents per on-call shift is too many?

Google gives a specific ceiling. The SRE Workbook states:

"We target a maximum of two incidents per on-call shift."

That number is often misquoted as "two to three." The primary source says two, and the reason is arithmetic about attention rather than a round-number preference. Each real incident consumes the follow-up work, the context switching, and the recovery time around it, not just the minutes of active response.

The definition of "incident" is the part most teams get wrong when they measure themselves. The same chapter is explicit:

"One 'incident' is defined as one 'problem,' no matter how many alerts have been fired for the same 'problem.'"

This matters enormously for how you read your own paging data. A team drowning in three hundred pages a week does not necessarily have an incident-volume problem. It may have one problem firing forty pages, which is a correlation problem. Counting pages tells you how loud the system is. Counting problems tells you how loaded the human is, and only the second number belongs against Google's ceiling of two.

What is the limit on operational work?

Incidents per shift is one axis. Total operational load is the other, and Google caps it directly. The SRE Book states:

"We cap the amount of time SREs spend on purely operational work at 50%"

with the further breakdown that "no more than 25% can be spent on-call, leaving up to another 25% on other types of operational, nonproject work." The remaining half is protected for engineering.

The cap is not generosity. It is the mechanism that stops a reliability team from degrading into a permanent firefighting unit. When operational work exceeds 50 percent, the engineering that would reduce future operational work never gets done, and the load compounds. Burnout in that regime is not a morale issue; it is the predictable output of a system with no slack.

How small can an on-call rotation get?

There is a floor on rotation size, and it is higher than most teams assume. Google's guidance:

"the minimum number of engineers needed for on-call duty from a single-site team is eight"

Below eight, the frequency each person carries rises past what is sustainable, and the follow-the-sun alternative (two six-person sites) exists precisely so that no individual absorbs night pages indefinitely. A four-person rotation is not a lean team. It is a rotation running below its structural minimum, and the exhaustion that follows is a staffing decision, not a personal weakness.

Metric	Google's stated limit	What it protects against
Incidents per on-call shift	"a maximum of two"	Attention exhaustion and skipped follow-up
Purely operational work	"at 50%"	Engineering collapsing into firefighting
On-call time within that	"no more than 25%"	Chronic paging load
Single-site rotation size	"eight" engineers minimum	Unsustainable individual frequency

If your rotation violates two or more of these, the burnout is structural, and no amount of tooling substitutes for fixing the staffing or the load.

Why does stress make incidents worse, not just unpleasant?

Burnout is not only a long-run cost. Stress degrades the quality of the response in the moment, and the SRE Book describes the mechanism directly. Stress hormones "can impair cognitive functions and cause suboptimal decision making," and under acute pressure:

"the more deliberate cognitive approach is typically subsumed by unreflective and unconsidered (but immediate) action."

That is the physiology of a 3am page. The engineer reaches for the fastest available action rather than the correct one, and the book names the specific failure that follows: it becomes "extremely tempting to exercise confirmation bias" by latching onto a familiar-looking cause. A tired responder is not just slower. They are measurably more likely to fix the wrong thing confidently, which turns one incident into two.

This is the strongest argument for reducing on-call load that has nothing to do with kindness. The output quality of a stressed rotation is worse, and the errors are self-reinforcing.

Where does alert fatigue actually come from?

Alert fatigue has a specific cause, and it is not weak engineers. The SRE Workbook locates it in the signal-to-noise ratio:

"a low signal-to-noise ratio raises the risk for on-call engineers to develop alert fatigue"

with the corresponding target that "the signal-to-noise ratio should be high to ensure few false positives." Every false page spends a unit of attention that a real page will later need, and a rotation trained by false positives to distrust its own alerts is one that will be slow on the page that matters.

The fix is upstream of the human. Cut false positives, and correlate the alerts that do fire so that one problem does not present as forty. That is deliberately not the same as muting alerts. Muting hides the signal; correlation groups it so the human sees one problem instead of a storm. The distinction is the whole subject of why muted alerts come back, and it is why noise reduction done by suppression tends to make the next incident worse.

What does the human cost look like in the data?

The physiological argument is qualitative. The organisational cost shows up in survey data. PagerDuty's 2026 State of AI-First Operations, based on "survey responses from 1,000 business leaders, IT decision makers and senior developers" and dated March 17, 2026, found respondents attributing to incidents the effects of "contributing to developer burnout (42%)," "reducing productivity (48%)," "introducing recovery costs (50%)," and "damaging brand reputation (52%)."

Treat these as leader self-reports rather than measured engineering outcomes, because that is what they are. But the direction is unambiguous and it matches Google's structural argument: incidents cost people, and a rotation loaded past its limits pays that cost first.

Where AI helps with on-call load, and where it does not

Here the tension has to be stated directly, because an AI SRE vendor writing about burnout has an obvious incentive to oversell.

Where it genuinely helps. The load Google caps is dominated by one expensive stage: investigation. Reading dashboards, correlating a deploy with an onset time, and assembling the evidence for a hypothesis is mechanical work that scales badly for a tired human at 3am. An agent that gathers that evidence quickly and hands over a cited chain of reasoning compresses the single most draining part of the shift. Correlating an alert storm into one incident, so the human sees one problem rather than forty pages, attacks the exact signal-to-noise problem the Workbook names. This is the honest case for AI investigation against burnout, and it is a real one.

Where it does not help, and can hurt. AI does not raise Google's ceilings. If a four-person rotation is below the eight-engineer floor, an agent does not fix the staffing. Worse, an agent that hands a stressed engineer a confident wrong root cause exploits the exact confirmation-bias failure the SRE Book warns about, because a tired responder has the least capacity to doubt it. That is why an investigation agent that cannot say "inconclusive" is a liability rather than a relief. The accuracy question is not academic here; on a burnt-out rotation, a plausible wrong answer is more dangerous than no answer.

Aurora's design encodes this limit rather than papering over it. Its sub-agent findings are rejected unless they state what was ruled out and a self-assessed confidence, and a timeout yields an honest inconclusive stub rather than a fabricated conclusion. That behaviour matters most for the exact rotation this post is about, and it is readable in the open repository rather than asserted here.

A checklist for measuring your own rotation

Before buying any tool, measure against the published limits.

1. Count problems, not pages. Collapse alerts that share a root cause into one incident, then check the per-shift count against Google's ceiling of two.
2. Measure operational percentage. If purely operational work exceeds 50 percent, that is the finding, and it is a load problem no tool solves.
3. Count the rotation. Below eight single-site engineers, the frequency is structurally too high. Fix staffing or move to follow-the-sun before optimising anything else.
4. Audit false-positive rate. Every non-actionable page is signal-to-noise debt. Cut the alert or make it actionable.
5. Separate correlation from muting. Group related alerts so one problem reads as one incident. Do not suppress, because a muted alert that comes back is a worse incident.
6. Only then consider investigation tooling. An agent compresses the investigation stage. It does not raise the ceilings, and it must be honest about uncertainty to be safe on a tired rotation.

The summary

Google's SRE organisation treats on-call burnout as an engineering problem with numbers attached: a maximum of two incidents per shift, operational work capped at 50 percent, and a floor of eight engineers per single-site rotation. Stress measurably degrades the quality of incident decisions, and alert fatigue traces to a low signal-to-noise ratio rather than to weak engineers. AI investigation helps with the most draining stage, evidence gathering, and with correlating storms into single incidents. It does not raise the ceilings, and an overconfident agent makes a tired rotation worse. Measure against the limits first. The tool comes after the staffing.

Compress the draining stage on your own stack

Aurora is Apache 2.0, so you can measure whether AI investigation actually reduces your rotation's load rather than trusting a claim. The only external requirement is one LLM API key; cloud connectors are optional.

git clone https://github.com/arvo-ai/aurora.git && cd aurora

make init                # generates secrets, copies .env.example to .env
nano .env                # add OPENROUTER_API_KEY (or OPENAI_API_KEY / ANTHROPIC_API_KEY)
make prod-prebuilt       # pulls prebuilt images from GHCR and starts

Open http://localhost:3000. The first user to register becomes admin.

• Start free: aurora-ai.net (hosted, no infrastructure to run)
• GitHub: github.com/Arvo-AI/aurora
• Related guides: Why Your Muted Alert Came Back · AI SRE Accuracy: What the Benchmarks Show · The SRE Incident Lifecycle · Root Cause Analysis for SREs

Sourcing note. On-call limits and the stress and alert-fatigue mechanisms are quoted from Google's SRE Book chapter "Being On-Call" and the SRE Workbook chapter "On-Call." The incident-impact percentages come from PagerDuty's 2026 State of AI-First Operations survey (N=1,000, dated March 17, 2026) and are leader self-reports rather than measured engineering outcomes. No Aurora burnout-reduction or MTTR figure is claimed, because none has been measured. Verified August 22, 2026.