Postmortems are good at capturing direct costs: time to detect, time to resolve, revenue lost during downtime, customer impact. They're not as good at capturing the costs that accumulate over time without any single triggering incident. Alert fatigue lives in this second category. You won't find it in any postmortem because no single alert woke someone up and caused a disaster. The damage is distributed across hundreds of small interruptions.
The math exists. It's just rarely assembled into a single view that makes the cost visible. This post is that assembly, and it's also an argument that fixing alert noise is a higher-leverage intervention than most engineering teams treat it as.
The direct paging cost: what most teams measure
Start with the number teams usually do track: pages per week. A reasonable engineering team paying attention to on-call health aims for something in the range of 1-3 actionable pages per 24-hour shift. The Google SRE book suggests this as a rough upper bound for sustainable on-call load. More than that, and the rotation starts accumulating toil faster than it can be addressed.
For a lot of teams running microservice stacks without noise reduction in place, the actual number looks more like 8-20 pages per shift, of which 60-70% are noise: rules that fired and self-resolved, duplicate alerts, post-deploy transient spikes. The engineer is woken up, investigates for 10-20 minutes, finds nothing, and goes back to sleep. This happens multiple times a night.
At a per-page investigation cost of 20 minutes fully burdened (wake-up, context load, investigation, acknowledgment, return to sleep) and 12 noise pages per 24-hour shift, you're looking at 4 hours of disrupted time per shift. Over a typical 7-day on-call rotation, that's 28 hours. That's most of a week's productive capacity, distributed across broken sleep and context-switching, before accounting for the productivity loss the next working day from disrupted sleep.
Sleep debt is not recoverable by the rotation cycle
The number that postmortems never capture: what does fragmented overnight sleep do to the quality of work the next day?
The research on this is fairly clear. Sleep disruption even once in the 4-6 hour window affects working memory, error rate in cognitive tasks, and response time the following day. The effects are measurable and significant. An engineer who was paged at 2am and 4am is not operating at full capacity at 10am in the morning standup, even if they feel fine. This isn't a wellness argument; it's an engineering reliability argument. If your on-call rotation is generating consistent overnight noise, you're systematically degrading the next-day judgment of the people who are supposed to maintain your systems.
This effect is especially pronounced for on-call rotations with short cycle times and limited engineers. A 4-person rotation means each engineer is on-call roughly one week in four. If each week on-call generates consistent overnight noise, that engineer is impaired the following workday once a month. Across a small team, that's a meaningful fraction of the team's cognitive capacity operating below baseline in any given month.
Rotation churn: the cost that shows up in hiring budgets
Alert fatigue is a known driver of SRE and platform engineer attrition. Not every resignation is primarily attributable to on-call load, but it's a consistent factor in exit conversations. The frustration is not usually "I got paged too many times last night." It's more specific: "I've been on-call for two years and the noise never got better, and I stopped believing it would."
When on-call load feels both high and futile, the best engineers leave first. They have the market options to do so. What remains is the people who either can't leave or have normalized the dysfunction. Neither outcome is good for the organization.
The replacement cost of a senior SRE or platform engineer varies by market and role, but the commonly cited range runs from 50-100% of annual compensation when you account for recruiting, interviews, onboarding, and the 3-6 month ramp to full productivity. For a role that was generating 4 hours of overnight disruption per week, some fraction of that cost is attributable to on-call quality. That fraction is hard to isolate, but it's not zero, and it shows up in hiring budgets every time the rotation loses a person.
We're not claiming alert noise is the only reason people leave platform roles. There are many factors. What we're saying is that it's a compounding one: it makes the role harder and less rewarding without directly contributing to anything meaningful. The pages that go nowhere don't build anything; they only consume time and trust.
The response quality degradation problem
There's a less-discussed second-order effect of alert fatigue: it degrades the quality of responses to real incidents.
When an engineer has been woken up 8 times in the past 72 hours and 7 of those were noise, the 8th page does not receive the same attention as the first would have. This is not a character failure; it's a conditioned response to a pattern. The engineer has learned that most pages resolve themselves. They've also learned that most pages are boring and require minimal action. This learned bias means that when a real incident fires, the initial investigation may be less thorough, the sense of urgency may be lower, and the time to appropriate escalation may be longer.
MTTD and MTTR metrics don't usually capture this. They measure outcomes, not the quality of the investigation process leading to those outcomes. A real incident that was resolved quickly because it was immediately obvious is counted the same as one that was resolved quickly despite a slow initial response because the root cause happened to be easy to see. The degradation is invisible until it isn't, which usually means until a real incident is missed or handled poorly.
What changes when you fix the noise
The math runs in the other direction if you reduce the noise. If you get from 12 noise pages per shift to 2, the direct time cost drops from 4 hours to 40 minutes per shift. The overnight sleep disruption drops from multiple wake-ups to one or zero. The rotation becomes something an engineer can do while also operating at full capacity the next day.
We've seen this shift described by teams who've worked through serious alert hygiene projects: the on-call rotation stops feeling like something to survive and starts feeling like something manageable. The pages that do come through are almost always real. Engineers start trusting the system again. That trust is hard to quantify, but it shows up in how seriously people take alerts, how quickly they investigate, and whether good engineers stick around for their next rotation cycle.
None of this requires heroic effort on the team's part. It requires acknowledging that the noise costs are real even when they're not in any postmortem, and that they're worth spending engineering time to address. The fix is not a single clever rule change; it's sustained attention to what's firing and whether it should be. ObsrvHQ is one way to systematize that attention. Alert hygiene sprints, regular rotation retrospectives, and noise-rate as a team health metric are others. The specific approach matters less than doing something, because the math doesn't improve on its own.