Why postmortem action items die

Most teams that run blameless postmortems are good at them. The timeline is accurate, the contributing factors are thoughtful, and the action items are sensible. Then, a quarter later, the same failure pages someone at 2am.

The analysis was fine. The follow-through was not.

What Google says goes wrong

Google’s SRE workbook includes a worked example of a weak postmortem, and the critique reads like a list of what happens on most teams. “Only one action item was assigned a tracking bug.” “All of the action items have been tagged with an equal priority.” The guidance that follows is just as direct: “Actions items without clear owners are less likely to be resolved,” and “Without a formal tracking process, action items from postmortems are often forgotten, resulting in outages” (Google SRE Workbook, Postmortem Culture).

The line I come back to most is this one: “To our users, a postmortem without subsequent action is indistinguishable from no postmortem.”

Four ways a good action item dies

It has no owner. “The team will look into pool sizing” is not owned by anyone. When the on-call week ends, so does the urgency.

It has no change attached. An action item that lives only in a document never enters the system the team actually plans from. It does not show up in sprint planning, so it does not get planned.

It cannot defend its priority. The item is competing with roadmap work that has a revenue story attached. “Resize the Redis pool” has no story at all, even if the pattern behind it has cost 112 engineering hours this year. Nobody wrote that number down.

It closes on merge. Even when the change ships, the ticket closes when the pull request merges. Nobody checks whether the failure class actually stopped. If the fix was incomplete, the next occurrence arrives under a new incident number and the history resets.

Root cause is not the bottleneck

It is tempting to think better analysis would solve this. The evidence suggests otherwise. The Verica Open Incident Database, which collected thousands of public incident reports, found that only about a quarter of them named a root cause at all, and its lead analyst, Courtney Nash, has argued that the hunt for a single root cause can narrow a team’s view rather than widen it (CSO Online on the VOID report).

You do not need a perfect root cause to prevent a recurrence. You need the preventive change to ship, and you need to know whether it worked.

What follow-through looks like

An action item that survives has four properties:

1. One named owner, not a team.
2. A real change: a pull request, a policy, or an RFC with a number.
3. A cost attached, so it can argue for its place in the plan.
4. A verification window. It stays open until the incidents it was meant to prevent have stopped for long enough to believe it.

The workbook also warns about incentives: if you reward engineers for writing postmortems but not for closing the associated action items, you get a library of excellent documents and the same incidents. Making the cost visible, and making “settled” mean “stopped recurring” instead of “ticket closed,” changes what gets rewarded.

Some of this is tooling and most of it is habit. The part tooling can help with is memory: when the same failure shows up again, the responder should be told immediately that it has happened before, what fixed it last time, and which action item would have prevented it. That is one of the reasons sudoSRE keeps incident memory as a layer of its Prod Map.