Your On-Call Rotation Isn't the Problem. Your Alert Volume Is.

Everyone blames on-call culture for burnout. Fewer people are willing to say the actual problem out loud: most on-call engineers aren't drowning in incidents, they're drowning in noise. Alert fatigue has quietly become the top reliability risk in production operations this year — ahead of insufficient automation, ahead of root-cause difficulty.

The pattern is almost always the same. A team adds alerting for every metric that could theoretically matter, nobody ever removes one, and five years later the on-call engineer can't tell a real page from the 2am noise their pager has cried wolf about for months. One SRE manager who deleted roughly 80% of their alerts cut their mean-time-to-acknowledge by 40%. Not by adding tooling. By removing noise.

Here's the uncomfortable part: this isn't a tooling problem, it's a culture problem. Nobody gets praised for deleting an alert. Everyone gets blamed when the one alert they deleted turns out to matter. So alerts accumulate forever, and the people paying for that accumulated caution are the engineers losing sleep to pages that didn't need a human at 2am.

My actual take: teams that treat "fewer alerts" as a reliability win instead of a risk are the ones who'll keep their senior engineers. The ones still measuring on-call health by alert coverage instead of alert signal-to-noise are going to keep losing their most experienced people to burnout, quietly, one resignation at a time.

How many of the alerts on your team's on-call runbook have actually required human action in the last 90 days?

#AWS #SRE #OnCall #DevOps #CloudComputing #Reliability #TechCulture #Observability #EngineeringLeadership #BuildOnAWS