Why post-mortem action items die

You can run the best debrief of your life. Honest timeline, blameless tone, real insights. People leave the room nodding.

And then nothing happens.

This is the last mile problem of post-mortems - and it's an easy trap to fall into. When you've just been through a stressful incident, getting it back up is the priority. Once it's over, the post-mortem itself can feel like the finish line. You've documented what happened, been honest about it, identified what went wrong. It feels like the work is done.

But the part where things actually get better happens after the meeting ends. And that part is genuinely hard to get right.

The most common frustration we hear from people running post-mortems isn't about templates, or blamelessness, or tooling. It's some version of: how do we make sure the follow-ups actually get done? It comes in many forms. How do we track them? Why won't engineers action them? What happens to the non-technical ones?

The pain is both universal and specific. And the honest answer is that most teams haven't fully solved it.

How actions die

There are four common ways post-mortem actions quietly expire. You'll probably recognise most of them.

Nobody owns it. "The team should improve monitoring" isn't really an action - it's a shared intention. When ownership belongs to a team, it effectively belongs to nobody. Nobody wakes up on Monday thinking "I should go work on that thing the team was supposed to do." A name is the difference between an intention and a commitment.

It lives in the wrong place. The action gets written into the post-mortem doc, or into a separate spreadsheet that someone set up with good intentions. Then the doc gets closed. The spreadsheet gets forgotten. If follow-ups don't live in the same tool as your actual work — Linear, Jira, whatever people open every day - they're already on borrowed time.

It's a direction, not a task. "Improve alerting" isn't something you can finish. There's no moment where you look at it and say "yes, done." It's a compass heading, not a destination. If an action doesn't have a verb you can verify - add, remove, change, test - it's more of a wish than a task.

Nobody checks. The debrief ends, the document gets published, people move on. Nobody asks at sprint planning: "what happened to the actions from last week's incident?" Nobody brings it up at on-call handoff. The chapter closes when the meeting does.

There's a fifth failure mode that's harder to talk about. When the real fix is "hire more engineers" or "change how team ownership works" or "address the incentive structure that leads people to cut corners under pressure" - those don't close like technical tasks do. They're systemic, they're uncomfortable, and they need someone with actual organisational authority to act on them. More on that in a moment.

What a good action item actually looks like

Here's a simple test. Compare these two:

Weak: "Improve monitoring"

Strong: "Alice: add alert for DB replication lag >30s in Datadog, by end of sprint 14"

The stronger one has five things: a name (Alice, not "the platform team"), a verb (add, not "improve"), a specific outcome (alert for DB replication lag >30s), a home in your actual tracker rather than a doc, and a deadline. You can look at it in two weeks and know whether it happened.

It's worth being honest about why weak actions get written in the first place. When you've just come out of a stressful incident, wrapping up the post-mortem feels like relief. Writing "improve monitoring" feels complete enough - it captures the spirit of what needs to happen, and in the moment, that can feel like enough. Nobody wants to slow down and get granular when everyone is tired.

But vague actions are actually harder to finish than specific ones, because nobody agrees on what "finished" means. Specificity isn't bureaucracy. It's clarity - and it's what makes the thing possible to close at all.

One more thing: the verb matters. "Review", "explore", "investigate" describe activity, not change. They're easy to start and impossible to finish in any meaningful sense. Prefer verbs that create a visible result: add, remove, change, update, test, deploy. If an action starts with "review", it's worth asking what decision that review leads to - and making that the actual action.

The systemic stuff is harder, and that's exactly why it gets dropped

Technical actions close easily. Add an alert. Update a runbook. Fix a config. Clear owners, clear definitions of done, fits neatly into a sprint.

But some of the most important things a post-mortem surfaces aren't technical. "Fix team ownership", "address the process that leads to corners getting cut", "clarify who's responsible for Component X" - these don't translate into sprint tickets. They're leadership problems, and they need to be treated as such.

The approach that tends to work: escalate with a concrete ask, not a vague concern. "Component X has no clear owner, which meant it took 40 minutes to find someone who could investigate during the last incident. Can we assign ownership to Team Y by end of month?" Frame it as a risk with a measurable consequence. Give it to someone at the right level. A named person with a specific request will always get further than an action item that says "resolve ownership ambiguity."

Accountability is not blame

This is the tension that makes people uncomfortable. Post-mortems are supposed to be blameless. But actions need owners. How do you assign ownership without it feeling like finger-pointing?

The distinction is actually pretty simple. Blame is backward-looking. Accountability is forward-looking.

"Alice should have had the alert in place" is blame - it assigns fault for something that's already happened. "Alice will add the alert by Friday" is accountability - it assigns ownership of something that still can. One makes people defensive. The other gives them something useful to do.

Naming this out loud in the debrief - "we're assigning ownership of the fix, not responsibility for the incident" - makes a real difference. Most engineers are happy to own a concrete fix. They're not happy to feel like they're being held accountable for a systemic gap they didn't create.

The follow-up ritual

Actions don't survive on good intentions. They survive on rhythm.

The most effective version of this isn't a new meeting or a new process - it's a standing question in the ceremonies you already have. At sprint planning or on-call handoff: "any open incident actions?" Two minutes. That's often all it takes to stop something falling through the cracks.

A light nudge from the incident owner a couple of weeks out can also go a long way - a quick message checking in on something isn't a performance review. It's just a human reminder that the thing exists and someone noticed it.

At a leadership level, visibility into a dashboard of open actions can help too. Not to micromanage, but to notice patterns. If the same type of action keeps sitting open for months, that's a signal - either it's not actually important enough to prioritise (in which case, consciously close it), or there's a structural blocker that needs attention from above.

And closing a post-mortem should be a deliberate act. Either the actions are done, or they've been explicitly deprioritised with a reason. "We decided not to do this because the risk is low and the effort is high" is a completely valid outcome. What tends to go wrong is the action quietly rotting in a backlog until it gets archived and forgotten.

Think of incident actions a bit like tech debt. Some will get done immediately. Some will get scheduled. Some will never get done - and that should be an explicit decision, not a slow drift into nothing.

Making the loop visible

People don't avoid follow-ups out of laziness. They avoid them when the actions feel disconnected from real work, when nothing visible happens if they don't do them, when the action was vague enough that starting it feels harder than ignoring it.

The most useful thing isn't a system of incentives - it's just making the connection between an action and an outcome visible. When an alert someone added after an incident catches a problem before it escalates - say so. In the next post-mortem, in your incident learning channel, wherever your team shares that kind of thing. "Remember the replication lag alert Alice added after the March incident? It fired last night and caught a failing replica before it affected customers."

That's the loop. Actions prevent incidents. Prevented incidents get noticed. People see that their follow-up work actually matters. It's not a reward system - it's just making reality visible.

The last mile

Post-mortems are only as good as the change they produce. A well-written document with vague, unowned, untracked actions is ultimately just a story - interesting, maybe even well told, but not a driver of improvement.

The fix isn't complicated. Name an owner. Use a real verb. Put it in your real tracker. Check on it. And when it works, tell people.

Learning doesn't end when the debrief closes. It ends when the action is done - or when someone looks at it and says "we're not going to do this, and here's why."

Everything else is just where learning goes to wait.

For more information on the post-mortem problem, check out our recent on-demand webinar.