The SRE community talks about on-call burnout primarily as a volume problem. Too many pages, too many nights interrupted, not enough rotation coverage. The proposed solutions follow from this framing: reduce alert volume, add more people to the rotation, enforce compensation time after heavy on-call weeks.
These interventions help. But they address a secondary cause. When we talk to engineers who have left on-call roles or pushed back hard against rotation participation, the explanation is rarely "there were too many pages." More often it's some version of: "I would get paged, spend 45 minutes staring at dashboards with no idea what was wrong, and then fix something that turned out to be a two-line config change. That happened three times in a week. I stopped trusting that my time and sleep were being spent on things that were worth it."
The core burnout driver is not volume. It's the mismatch between the cognitive and emotional cost of being paged and the sense of control or competence you feel during the response.
The Helplessness Component
There's a useful concept from organizational psychology: burnout is most reliably induced not by hard work or long hours, but by hard work combined with perceived low control over outcomes. An on-call engineer who gets paged, finds the problem within two minutes, and fixes it in ten minutes feels tired but not demoralized. The same engineer paged for an ambiguous alert, spending 90 minutes debugging across systems they don't fully own, and finally implementing a speculative fix they're not sure will hold, feels something qualitatively different. The second experience, repeated over months, is what produces burnout.
The control variable here is almost entirely determined by how quickly the engineer can form a confident understanding of what's wrong. Not necessarily how quickly they can fix it, though that matters too. The understanding is the critical bottleneck. Engineers can tolerate hard fixes. They struggle to tolerate extended periods of not knowing what they're fixing or why.
Alert Fatigue Is a Symptom, Not the Disease
Alert fatigue gets conflated with on-call burnout, but they're distinct problems with different root causes. Alert fatigue is about signal quality: too many alerts that either don't need human attention or don't provide enough context to act on. Burnout is about the cumulative experience of the on-call role over time.
Alert fatigue contributes to burnout because noisy alerts train engineers to distrust the alerting system. When 40% of pages lead to "it resolved itself before I could find anything," engineers stop taking pages seriously, and that desensitization erodes the mental sharpness needed for the pages that do matter. The result is both slower response and more cognitive cost per incident because the engineer has to first decide whether this page is real before they start diagnosing.
But you can fix alert fatigue entirely, reduce your page volume by 60%, and still have engineers burning out if the remaining pages produce the long-diagnostic-gap experience. Volume reduction is necessary but not sufficient.
What the Diagnostic Gap Costs Cognitively
There's a specific type of cognitive load involved in investigating an unfamiliar system under time pressure. You're holding multiple hypotheses simultaneously, evaluating evidence against each, updating your model as new signals come in, while also feeling the urgency of a live incident affecting users. This is working-memory-intensive, anxiety-inducing work, and it has a known cost: it degrades decision quality over time and produces specific stress physiology (elevated cortisol, disrupted sleep patterns) that is slow to recover from.
The difference between a 5-minute diagnostic gap and a 45-minute one is not just 40 minutes of time. It's 40 minutes of high-load uncertain reasoning under pressure, often in the middle of the night, which has qualitatively more physiological impact than 40 minutes of focused but certain work. This is why reducing the diagnostic gap matters for burnout prevention, not just for MTTR metrics.
The Service Ownership Problem
A structural contributor to diagnostic uncertainty in growing engineering teams is the gradual erosion of service ownership on the on-call rotation. A team of 4 engineers might own 20 services. Each engineer owns a few intimately and has surface-level familiarity with the rest. The rotation means an engineer can be paged for any of the 20 services on any given night.
When you're paged for a service you didn't build and rarely touch, your diagnostic toolbox is shallow. You know how to find the logs, maybe. You know which Grafana dashboard to open, if there is one. You don't know the service's common failure modes, the "fingerprint" of its previous incidents, or the mental model of why certain metric patterns indicate certain problems. You're starting from scratch with every unfamiliar service page, which means your diagnostic gap is structurally longer.
The conventional fix for this is runbooks: documented procedures for known failure modes. Runbooks help, but they have a real limitation: they only cover known failure modes, and they're only as current as the last time someone updated them. Novel failures and services whose runbooks haven't been maintained since the original engineer left the team both fall through the runbook crutch.
A better approach is to surface institutional memory rather than just documented procedures. When you're paged for a service you don't know well, the most valuable thing you could receive is: here are the last five incidents on this service, here's what they had in common, here's the telemetry pattern that preceded each one. That's context a runbook doesn't capture because it requires live correlation with the service's incident history.
Rotation Design for Reducing Burnout, Not Just Coverage
Most on-call rotation design is optimized for coverage: ensuring there's always someone available. Optimizing for engineer experience in the rotation requires additional design decisions that aren't about coverage at all.
Primary/secondary rotations, where the primary is always someone who owns the alerting service and the secondary provides coverage backup, dramatically reduce the unfamiliar-service problem. The engineer who built the service and knows its failure modes handles the page. The cost is that this concentrates on-call burden on service owners, which creates a different fairness problem. Growing teams often can't afford primary/secondary for every service because they don't have the headcount.
A middle path is to pair engineers explicitly during rotation transitions: the outgoing on-call primary shadows the incoming one for a day, sharing recent incident context and service-specific knowledge. This is informal knowledge transfer that can meaningfully reduce first-night diagnostic confusion for the new primary.
We're not saying rotation redesign alone solves burnout. It addresses the service ownership dimension but not the diagnostic tooling dimension. The structural fix is ensuring that when an engineer picks up a page for any service in the rotation, they have fast access to the correlation context needed to form a quick hypothesis. Better tooling and better rotation design are complementary, not substitutes.
What Doesn't Work: The Volume-Only Fix
We've watched teams invest heavily in alert volume reduction and see diminishing returns on burnout improvement. They'll spend three months tuning thresholds, adding inhibition rules in Alertmanager, and suppressing noisy alerts during low-traffic hours. Page volume drops 40%. Burnout remains elevated.
The reason is that the remaining pages, the ones that weren't suppressed because they represent real incidents worth waking someone up for, still produce long diagnostic gaps. The engineers are paged less often, but the proportion of pages that leave them feeling helpless is unchanged or even higher (because the easy false-positive pages are gone and what's left are genuinely ambiguous real incidents).
Measuring burnout risk requires tracking the diagnostic experience, not just page volume. Ask your on-call engineers: on a 1-5 scale, how confident were you about the cause when you started fixing this incident? Track that over time alongside page volume. You'll get a much clearer picture of where the burnout pressure actually lives.
The path to sustainable on-call isn't just fewer pages. It's pages that come with enough context to act on immediately, and a diagnostic process that doesn't leave engineers in prolonged uncertainty. That's a different engineering problem than alert tuning, and it has different solutions.