The On-Call Trap: How Incident Response Culture Is Quietly Dismantling Your Engineering Workforce
When a senior engineer resigns, the exit interview rarely names the real reason. Compensation gets mentioned. Career growth comes up. Occasionally there is a comment about team dynamics or leadership. What almost never appears in the formal record — but surfaces consistently in the conversations that happen afterward, in Slack messages and over coffee and in the candid post-mortems that organizations rarely conduct about their own people — is the cumulative weight of being woken up at 2 a.m. for an alert that turned out to be a noisy threshold on a non-critical service. Again.
On-call culture has become one of the most significant and least discussed drivers of attrition in the US technology industry. The mechanisms are not mysterious. Sleep disruption, sustained hypervigilance, the psychological burden of carrying a pager through weekends and family events — these are well-documented stressors with measurable effects on cognitive function, decision-making quality, and long-term health. What is less well understood is how organizational design choices either amplify or contain these effects, and why so many engineering organizations default to arrangements that reliably produce the worst outcomes.
When Alerting Systems Become Adversarial
The technical architecture of an alerting system encodes a set of assumptions about what matters, how urgently it matters, and who is responsible for addressing it. When those assumptions are not revisited regularly — or when they were never examined carefully in the first place — the system tends to drift toward a configuration that is adversarial to the people it nominally serves.
Alert fatigue is the most commonly cited symptom of this drift, but the term understates the mechanism. What happens in practice is not simply that engineers receive too many notifications. It is that they receive enough false positives and low-priority pages that they can no longer reliably distinguish signal from noise under conditions of fatigue and time pressure. This is not a minor inconvenience. It is a degradation of the cognitive environment in which incident response decisions are made — which means it is, ultimately, a reliability problem as well as a retention problem.
Research published by PagerDuty and independently corroborated by studies in occupational health literature suggests that engineers who receive more than two actionable pages per week outside of business hours show significantly elevated burnout indicators within six to twelve months. The operative word is actionable: pages that require genuine human judgment and intervention, as distinct from noise that resolves before the engineer has finished reading the alert body.
Organizations that have not audited their alert signal-to-noise ratio in the past twelve months are almost certainly operating with a higher noise floor than they realize. Alert thresholds that made sense for a service at a particular scale or architecture often persist unchanged through multiple rounds of infrastructure evolution, accumulating false positive potential with each iteration.
The Extractive Model and Its Costs
There is a distinction worth drawing carefully between on-call arrangements that are demanding and those that are extractive. Demanding on-call is a reasonable feature of operating production systems at scale. Incidents happen. Some of them happen at inconvenient hours. Engineers who build and operate complex distributed systems understand this and, in most cases, accept it as part of the professional context.
Extractive on-call is something different. It is characterized by rotation structures that concentrate burden on a small number of individuals, by the absence of meaningful recovery time after significant incidents, by an organizational norm that treats availability as a measure of commitment rather than a function of system design, and by the implicit expectation that engineers will absorb on-call stress as a personal cost rather than as an organizational liability.
The financial consequences of the extractive model are poorly accounted for in most organizations. The direct cost of replacing a senior engineer in the US market — recruiting fees, interviewing time, onboarding, and the productivity gap during the ramp period — typically ranges from 50 to 200 percent of annual compensation, depending on seniority and specialization. When attrition is concentrated among engineers with the deepest system knowledge, the institutional cost compounds: the people who leave are disproportionately the ones who understood the systems well enough to resolve incidents quickly, which means their departure increases both incident frequency and mean time to resolution for those who remain.
This is a feedback loop with a predictable trajectory. Organizations that do not interrupt it tend to find themselves in a position where on-call burden has increased, team experience has decreased, and the remaining engineers are absorbing both the operational load and the organizational anxiety that comes with knowing the situation is unsustainable.
What Sustainable Incident Response Actually Requires
The organizations that have made genuine progress on this problem share a common starting point: they stopped treating on-call burnout as a people management issue and started treating it as an architecture and process issue. The framing matters because it determines where solutions are sought.
If burnout is a people management problem, the interventions tend to be interpersonal — better communication, mental health resources, manager coaching. These are not without value, but they do not address the underlying conditions. If burnout is an architecture and process problem, the interventions target the systems and structures that generate the burden in the first place.
Several practices distinguish organizations with sustainable on-call cultures from those without.
Alert ownership with accountability for quality. When the team that writes the alerting logic is also the team that receives the pages, there is a direct feedback loop between alert quality and engineer experience. This is the organizational equivalent of the software principle that whoever writes the code should be responsible for its maintainability. Centralized alerting configurations managed by a separate operations team break this feedback loop and tend to accumulate noise over time.
Explicit recovery time after significant incidents. An incident that requires two hours of active response at 3 a.m. represents a genuine cost to the engineer involved. Organizations that acknowledge this by providing compensatory time off — and that make this practice explicit rather than leaving it to individual manager discretion — signal that the cost is recognized and that it will not simply be absorbed invisibly.
Rotation breadth calibrated to incident volume. On-call rotations that are too narrow concentrate burden in ways that are unsustainable. A general heuristic that has gained traction among reliability engineering practitioners is that no engineer should expect more than two to three primary on-call weeks per quarter. Organizations whose team size makes this impossible have a staffing problem that cannot be solved by process alone.
Post-incident reviews that examine systemic conditions, not individual performance. Blameless post-mortems are a well-established practice, but their scope is often too narrow. Reviews that focus exclusively on the technical sequence of events miss the organizational conditions — understaffed rotations, deferred reliability work, alert configurations that were known to be problematic — that shaped the incident. Expanding the scope of post-incident review to include these factors creates organizational visibility into the conditions that generate both incidents and burnout.
The Retention Calculus
There is a straightforward business case for investing in sustainable incident response design, and it does not require appeal to engineer wellbeing to be compelling, though that appeal is legitimate on its own terms. The cost of building reliable, well-calibrated alerting systems and well-structured on-call rotations is a fraction of the cost of the attrition that poorly designed systems reliably produce.
The engineers who leave because of on-call culture are, systematically, among the most experienced and capable members of the organization. They have options. They exercise them. The organizations that recognize this dynamic early enough to redesign their incident response systems around sustainability rather than extraction tend to find that reliability and retention improve together — which is, on reflection, exactly what the evidence would predict.