I read every postmortem our team wrote over eighteen months looking for a pattern. There was one, and it wasn't the one I expected.

I read every postmortem our team wrote over eighteen months looking for a pattern. There was one, and it wasn't the one I expected.

What I Thought I'd Find

Going in, my guess was that most incidents would trace back to bad deploys — code that should have been caught in review or CI. That's the story we tell in retros most often because it's the most legible: a diff, a bug, a rollback. Reading fifty postmortems end to end told a different story.

The Actual Breakdown

I tagged each incident's root cause into one of six buckets and ran the count:

from incidents
| where resolved_at >= "2024-09-01"
| summarize count() by root_cause_category
| sort by count() desc

Bad deploys accounted for 31% — real, but not the majority I expected. Capacity and scaling issues (a limit hit under organic growth, not a sudden traffic spike) were 24%. Configuration drift — a setting changed in one environment and never reconciled with others — was 19%. Dependency failures, where the actual bug was in a third-party service or shared internal platform team's system, was 16%. The remaining 10% were genuinely novel: things like the clock-skew page and the Tuesday memory leak, each unlikely to recur in the same shape.

Why the Deploy Story Dominates Our Memory

Deploy-caused incidents are the easiest to tell a clean story about: commit, bug, fix, done. Capacity and config-drift incidents are messier — they accumulate over weeks and the "root cause" is really a slow erosion of margin, which doesn't make for a satisfying five-minute retro narrative. I think that's exactly why they're underrepresented in how teams talk about reliability even though they're a bigger share of the actual pain. We've since started a lightweight quarterly review specifically for capacity margins and config drift, separate from incident retros, because waiting for an incident to surface them is the expensive way to find out.

The incidents that are hardest to tell a story about are often the ones worth the most attention.
  • Across 50 postmortems, capacity and config drift combined outnumbered bad deploys as root causes.
  • Deploy-caused incidents get remembered more vividly because they have a cleaner narrative arc.
  • Slow-erosion causes (margin, drift) need their own proactive review cadence, not just retro attention.
  • Tag root causes consistently across postmortems so you can actually run this kind of aggregate query later.