Your team runs postmortems. They’re calm, they’re blameless, everyone nods, action items get assigned. And six weeks later the same class of incident happens again. The postmortem didn’t fail because it assigned blame. It failed because it changed nothing.
“Blameless” has become the entire point, and that’s the problem. A postmortem that produces a good feeling and a filed document is theatre. A postmortem is only worth the hour it takes if the system is measurably less likely to fail the same way afterwards.
Blameless Was Never the Goal
Blamelessness is a precondition, not an outcome. The reason you don’t blame the engineer who ran the bad migration is not to spare their feelings. It’s because blame is a lie about how failures happen.
Systems fail because of the conditions around a decision, not the person who made it. The engineer ran the migration at 5 PM on a Friday because there was no policy against it, no automated guard, and no second reviewer required. If you fire that engineer, the next one runs the same migration on the next Friday, because none of those conditions changed. Blame lets you stop investigating exactly when the useful investigation begins.
So blameless culture buys you honesty. People tell you what actually happened instead of what protects them. But honesty is fuel, not a destination. If you get the honest account and then do nothing structural with it, you’ve built a very civilised way of learning nothing.
The Postmortem That Changes Nothing
You’ve seen this document. It has these hallmarks:
- A timeline and nothing else. Minute-by-minute reconstruction of what happened, which reads like a police report and generates no change. The timeline is evidence, not conclusion.
- Root cause: “human error.” The investigation stops at the person. This is blame wearing a lab coat. “Human error” is never a root cause; it’s the place where the real questions start.
- Action items that are actually feelings. “Be more careful with migrations.” “Improve communication during incidents.” These aren’t changes. You cannot assign, verify, or complete “be more careful.” They exist to make the document feel complete.
- No owner, no date, no verification. Action items assigned to “the team” with no deadline and no one checking whether they shipped. This is where postmortems go to die — the meeting ends, the document is filed, and everyone moves on to the sprint.
The tell is simple: if you can’t point to a specific change in the system that resulted from the last five postmortems, you don’t have a postmortem process. You have an incident memorial service.
What a Postmortem That Works Actually Does
Three shifts turn the ritual into a mechanism.
Ask “why” until you hit something you can change
“The database ran out of connections.” Why? “A background job opened connections in a loop and didn’t close them.” Why did that reach production? “There’s no load test for connection usage and no review checklist that catches it.” Why not? “Nobody owns the review checklist.”
Now you’re somewhere useful. Every “why” that lands on a person is a why you stopped too early. Keep going until you land on a missing guard, a missing test, a missing owner, a missing alert. Those are things you can build. “Be careful” is not.
Write action items you can actually verify shipped
A real action item has an owner, a date, and a definition of done that someone else can check. “Add a connection-pool exhaustion alert with a burn-rate threshold, owned by Priya, done when it fires in staging under load — by the 20th.” That’s a change. Compare it to “monitor the database better.” One of these ships. The other is a wish.
And there’s a cap. If a postmortem produces fifteen action items, none of them will happen — the list is too big to track and everyone assumes someone else has the important ones. Two or three that actually ship beat fifteen that decorate a document.
Feed the fixes back into monitoring and alerting
The best action item from most incidents is a new signal. If this failure was invisible until a customer complained, the fix is not just “handle this case” — it’s “detect this case next time.” Every incident should leave your monitoring smarter than it was before. That’s the compounding improvement loop, and it’s the entire reason to run postmortems at all. Skip it and you’re fighting the same fires with rising fatigue.
The Part Nobody Wants: Closing the Loop
Here’s the uncomfortable truth about why postmortems fail. It’s not the meeting. Teams are good at the meeting. It’s the four weeks after, when the action items compete with feature work and lose. The postmortem was urgent because the incident was fresh. By the next sprint it’s a memory, and the fix that would prevent the recurrence sits in the backlog behind three customer requests.
Closing the loop is unglamorous, ongoing accountability work: tracking whether the action items actually shipped, re-opening the ones that didn’t, and confirming the new alert actually fires. Nobody is measured on it, so on a busy team it’s the first thing to slip. That’s why the same class of incident recurs — not because the team didn’t understand it, but because nobody owned the follow-through.
An incident is only genuinely resolved when the change that prevents its recurrence is live and verified. Everything before that is just knowing what went wrong, which is a different thing from being less likely to have it go wrong again.
Make the Loop Someone’s Job
The teams whose reliability actually improves aren’t smarter about incidents. They’re more disciplined about the boring part: they turn each incident into a specific, verified change, and someone owns making sure that change ships. The postmortem meeting is easy. The follow-through is the whole game.
Vigil by IOanyT runs the postmortem loop as a managed function — we diagnose the incident, turn it into verifiable changes, wire the new signals into your monitoring, and close the loop so the same failure doesn’t come back next month.
Your engineers build. We make sure each incident makes the system stronger.
