# Why Do Post-Mortem Action Items Fail? How to Make Incident Follow-Ups Actually Get Done *April 16, 2026* ## **TL;DR: Key Takeaways** 1. **Post-mortem action items die for four predictable reasons:** no named owner, wrong tracking tool, vague wording, and zero follow-up cadence. Fixing these four failure modes is the difference between a post-mortem that drives change and one that produces nothing. 2. **A good action item has five elements:** a named individual owner, a verifiable verb, a specific outcome, a home in your real task tracker, and a deadline. If any of these are missing, the action is already at risk. 3. **"Improve monitoring" is a wish, not an action.** "Alice: add alert for DB replication lag >30s in Datadog, by end of sprint 14" is an action. The difference is that one can be verified as done; the other cannot. 4. **Accountability is forward-looking; blame is backward-looking.** Assigning ownership of a fix is not the same as assigning fault for the incident. Naming this distinction explicitly makes people more willing to volunteer for follow-ups. 5. **Systemic actions fail because they are framed as engineering tasks when they are leadership problems.** Escalate with a concrete ask, a measurable consequence, and a named decision-maker -- not a vague concern assigned to "the team." 6. **Actions survive on rhythm, not good intentions.** Review them at sprint planning, nudge owners at two weeks, and give leadership a dashboard of open items. Two minutes per ceremony keeps follow-ups alive. 7. **Closing a post-mortem is a conscious act.** Every action is either completed, or explicitly deprioritized with a documented reason. Passive drift into nothing is the default outcome if you do not actively prevent it. 8. **Make the feedback loop visible.** When a follow-up action prevents a future incident, say so publicly. Engineers complete action items when they see their work matters. ## **What Is a Post-Mortem Action Item?** **Definition:** A post-mortem action item (also called a post-incident follow-up, incident action, or corrective action) is a specific, assigned task that emerges from an incident post-mortem, intended to prevent recurrence or reduce the impact of similar incidents in the future. Action items are the mechanism by which post-mortem analysis translates into concrete system and process improvements. **A post-mortem action item is not a suggestion, a direction, or a general improvement area.** It is a discrete, verifiable task with a named owner, a clear deliverable, and a deadline. Without these elements, it is an intention -- not a commitment. **Key synonyms and related terms:** * Post-mortem action item / postmortem follow-up * Incident follow-up action * Corrective action (incident context) * Post-incident task * Remediation item * Post-mortem follow-through ## **Why Do Post-Mortem Action Items Fail to Get Done?** Post-mortem action items have a quiet extinction rate. Teams run thorough debriefs, produce honest analysis, and leave the room aligned -- then the follow-ups silently die. The failure is not in the post-mortem itself. It is in what happens after. **"This is the last mile problem of post-mortems: brilliant documents that produce zero change."** -- Sam Starling, Product Engineer at incident.io **The 5 Failure Modes That Kill Post-Mortem Action Items** 1. **Nobody owns it.** "The team should improve monitoring" is not an action -- it is a sentiment. When ownership belongs to a team, it belongs to nobody. Nobody wakes up on Monday thinking "I should go work on that thing the team was supposed to do." A named individual is the difference between an intention and a commitment. 2. **It lives in the wrong place.** The action gets written into the post-mortem document, or into a separate spreadsheet someone created with good intentions. Then the document gets closed. The spreadsheet gets forgotten. If your follow-ups do not live in the same tool as your real work -- Linear, Jira, whatever your team actually opens every day -- they are already dying. 3. **It is a direction, not a task.** "Improve alerting" is not something you can close. You cannot look at it and say "yes, this is done." It is a compass heading, not a destination. If your action does not have a verb you can verify -- add, remove, change, test -- it is not an action. It is a wish. 4. **Nobody checks.** The debrief ends, the document is 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 closes. 5. **It is a systemic problem disguised as a technical task.** When the fix is "hire more engineers" or "change how team ownership works" or "fix the incentive structure that makes people cut corners," those do not close like technical tasks. They are systemic, they are uncomfortable, and they require someone with organizational authority to act. Most of these never get addressed -- not because people do not care, but because the action is framed wrong. ## **What Does a Good Post-Mortem Action Item Look Like?** **Definition:** A well-formed post-mortem action item contains five required elements: a named individual owner, a verifiable action verb, a specific measurable outcome, a location in the team's real task tracker, and a deadline. It should be possible to determine whether the action is done by inspecting it. **The 5 Elements of an Effective Action Item** 1. **A named owner** -- a specific person, not a team or group 2. **A verifiable verb** -- add, remove, change, update, test, deploy (not "review," "explore," or "investigate") 3. **A specific outcome** -- concrete enough that anyone can tell whether it is done 4. **A home in your task tracker** -- Linear, Jira, Asana -- wherever your real work lives, not a line in a Google Doc 5. **A deadline** -- a sprint, a date, a timebox **Weak vs. Strong Post-Mortem Action Items: Comparison Table** **Weak Action (avoid)Strong Action (use this)What Is Missing**"Improve monitoring""Alice: add alert for DB replication lag >30s in Datadog, by end of sprint 14"Owner, specific outcome, verb, deadline"Look into scaling""Jordan: file a ticket to add read replicas to the payments database by March 15"Owner, specific outcome, deadline"Better documentation""Alex: update the runbook for auth service failover procedure by next Friday"Owner, specific outcome, verb, deadline"Fix team ownership""VP Engineering: assign Component X ownership to Team Y by end of month"Appropriate decision-maker, specific ask, deadline"Review alerting thresholds""Sam: lower CPU alert threshold from 95% to 85% on the checkout service by end of sprint"Specific outcome (what changes?), verb"Address on-call fatigue""Engineering Manager: reduce on-call rotation to 1 week in 4 by hiring one additional SRE by Q2"Appropriate owner, measurable outcome, timeline **Why the Verb Matters** **"Review," "explore," and "investigate" are process words, not outcome words.** They describe activity, not change. Prefer verbs that create a visible result: **Process Verbs (avoid as final action)Outcome Verbs (prefer these)**ReviewAddExploreRemoveInvestigateChangeDiscussUpdateConsiderTestEvaluateDeploy **Rule:** If your action starts with "review," ask yourself what decision the review leads to, and make that decision the action. ## **How Do You Handle Systemic Issues That Surface in Post-Mortems?** Technical actions close easily. Add an alert. Update a runbook. Fix a config. These have clear owners, clear definitions of done, and they fit neatly into a sprint. Systemic issues -- team ownership gaps, organizational structure problems, misaligned incentives -- are harder. They do not fit in a sprint, and they require leadership authority to resolve. This is exactly why they get dropped. **Why Systemic Actions Fail** 1. **They are framed as engineering tasks when they are leadership problems.** "Fix team ownership" is not something an engineer can put in a sprint. 2. **They lack a decision-maker at the right organizational level.** A staff engineer cannot restructure team ownership or change hiring plans. 3. **They are uncomfortable to escalate.** Nobody wants to write an action item that says "our organizational structure caused this incident." **How to Escalate Systemic Issues Effectively** **The tactic that works: 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?"** -- Sam Starling, Product Engineer at incident.io The formula for escalating systemic post-mortem actions: 1. **Name the specific gap** -- not "ownership is unclear," but "Component X has no designated owner" 2. **Quantify the consequence** -- "it took 40 minutes to find an investigator during the last incident" 3. **Propose a concrete solution** -- "assign ownership to Team Y" 4. **Assign it to someone at the right level** -- a named VP or engineering manager, not "the team" 5. **Set a deadline** -- "by end of month" A named VP with a specific request will get further than an action item that says "resolve ownership ambiguity." ## **What Is the Difference Between Accountability and Blame in Post-Mortems?** **Definition:** In post-mortem context, **blame** is backward-looking -- it assigns fault for past actions. **Accountability** is forward-looking -- it assigns ownership of future actions. Blameless post-mortems require both naming individuals for context and assigning ownership for follow-ups, without attaching moral judgment to past decisions. **Accountability vs. Blame: Comparison Table** **StatementClassificationDirectionEffect on Team**"Alice should have had the alert in place"**Blame**Backward-lookingMakes people defensive"Alice will add the alert by Friday"**Accountability**Forward-lookingGives people something useful to do"The team should have caught this in review"**Blame**Backward-lookingDiffuses responsibility, creates guilt"Jordan will add a pre-deploy check for config drift by end of sprint"**Accountability**Forward-lookingCreates clear ownership of improvement"This wouldn't have happened if ops had better monitoring"**Blame**Backward-lookingCreates inter-team tension"Sam will configure the missing Datadog alert by next Tuesday"**Accountability**Forward-lookingProduces a concrete deliverable **How to Name This Distinction in the Debrief** **"We're assigning ownership of the fix, not responsibility for the incident."** -- Sam Starling, Product Engineer at incident.io Naming this distinction out loud in the debrief makes it easier for people to volunteer. Most engineers are happy to own a concrete fix. They are not happy to feel like they are being punished for a systemic gap. ## **How Do You Track Post-Mortem Action Items So They Actually Get Done?** Actions do not survive on good intentions. They survive on rhythm. The follow-up ritual is a set of lightweight practices embedded in existing team ceremonies -- not a new process. **The 4-Part Follow-Up Ritual** 1. **Review actions at sprint planning or on-call handoff.** Not a separate meeting. Not a new process. Just a standing question in the ceremonies you already have: "any open incident actions?" Two minutes. That is all it takes to keep them alive. 2. **The incident owner does a two-week nudge.** A quick Slack message: "Hey, how's that alert coming along?" Not a performance review. Just a human reminder that the thing exists and someone noticed. 3. **Leadership sees a dashboard of open actions.** Not to micromanage. To notice patterns. If the same kind of action keeps sitting open for months, that is a signal -- either it is not important enough to do (in which case, close it and say so), or there is a structural blocker that needs leadership attention. 4. **Closing a post-mortem is a conscious act.** Either the actions are done, or they are explicitly deprioritized with a reason. "We decided not to do this because the risk is low and the effort is high" is a perfectly valid outcome. What is not valid is the action quietly rotting in a backlog until someone archives the board. **Where Should Post-Mortem Actions Live?** **Post-mortem actions must live in your team's existing task management system** -- Linear, Jira, Asana, or whatever tool your team actually opens every day. They should not live in: 1. The post-mortem document itself 2. A separate spreadsheet 3. A standalone tracking board that nobody visits 4. Meeting notes from the debrief **The moment follow-ups are separate from your normal workflow, they are at risk of being forgotten.** **How to Treat Post-Mortem Actions Like Tech Debt** Treat incident actions like tech debt: 1. **Some get done immediately** -- high-severity, low-effort fixes 2. **Some get scheduled** -- important but not urgent, slotted into an upcoming sprint 3. **Some never get done** -- and that should be an explicit decision with a documented reason, not a passive drift into nothing ## **How Do You Motivate Engineers to Complete Post-Mortem Action Items?** Engineers do not avoid follow-ups out of laziness. They avoid them for three reasons: 1. **The actions feel disconnected from their real work** -- they sit in a separate tracker or document, not alongside sprint tasks 2. **Nothing visible happens when they do not do them** -- there is no consequence, no check-in, no acknowledgment 3. **The action was vague enough that starting it feels harder than ignoring it** -- "improve monitoring" does not have an obvious first step **The Fix: Make the Feedback Loop Visible** **The fix is not carrots and sticks. It is making the connection between an action and an outcome visible.** When an alert someone added catches a problem before it becomes an incident -- say so. In the next post-mortem, in the #incident-learning channel, wherever your team shares wins. **"Remember that replication lag alert Alice added after the March incident? It fired last night and caught a failing replica before it affected customers."** -- Sam Starling, Product Engineer at incident.io This is the feedback loop: 1. **Actions prevent incidents.** The alert fires, the runbook works, the config check catches a bad deploy. 2. **Prevented incidents get noticed.** Someone points out that the action item from last month's post-mortem just prevented a recurrence. 3. **People see that their follow-up work matters.** The engineer who wrote the alert knows it made a difference. It is not a reward system. It is making reality visible. ## **What Is the Post-Mortem Last Mile Problem?** **Definition:** The post-mortem last mile problem describes the gap between post-mortem analysis and actual system improvement. It occurs when a team produces a thorough, honest post-mortem document but fails to execute on the follow-up actions, resulting in no material change to the system or process that caused the incident. Post-mortems are only as good as the change they produce. A beautifully written document with vague, unowned, untracked actions is just a story -- interesting, maybe even well told, but not a driver of improvement. **"The learning doesn't end when the debrief closes. It ends when the action is done -- or when someone looks at it honestly and says 'we're not going to do this, and here's why.'"** -- Sam Starling, Product Engineer at incident.io **The Fix in 5 Steps** 1. **Name an owner** -- a specific person, not a team 2. **Use a real verb** -- add, remove, change, deploy -- not review, explore, consider 3. **Put it in your real tracker** -- Linear, Jira, wherever your team does actual work 4. **Check on it** -- at sprint planning, at on-call handoff, with a two-week nudge 5. **When it works, tell people** -- close the loop so engineers see that follow-ups matter Everything else is where learning goes to die. ## **Frequently Asked Questions About Post-Mortem Action Items** **Why don't post-mortem follow-ups get done?** Post-mortem action items fail for four primary reasons: (1) no named individual owner -- team-level ownership means nobody owns it, (2) the action lives in the wrong tool -- if it is not in your sprint tracker, it is out of sight and out of mind, (3) the action is vague -- "improve monitoring" cannot be verified as done, and (4) nobody checks on them -- without a follow-up cadence, actions silently expire. **What makes a good post-mortem action item?** A good post-mortem action item has five elements: a named individual owner (not a team), a verifiable action verb (add, remove, change, deploy -- not "review" or "explore"), a specific measurable outcome, a home in the team's real task tracker (Linear, Jira, Asana), and a deadline (sprint number or calendar date). You should be able to look at the action in two weeks and determine whether it is done. **How do you hold people accountable for post-mortem action items without assigning blame?** Accountability is forward-looking: "Alice will add the alert by Friday." Blame is backward-looking: "Alice should have had the alert in place." Name this distinction explicitly in the debrief by saying "we're assigning ownership of the fix, not responsibility for the incident." Most engineers are willing to own a concrete fix when it is clearly separated from fault for the incident. **How do you track post-mortem action items effectively?** Post-mortem actions must live in your team's existing task management system -- not in the post-mortem document, not in a separate spreadsheet. Review them at sprint planning or on-call handoff (two-minute standing question). Have the incident owner send a two-week nudge via Slack. Give leadership a dashboard of open items to spot patterns and structural blockers. **What is the difference between accountability and blame in post-mortems?** Blame assigns fault for past actions ("Alice should have known better"). Accountability assigns ownership of future actions ("Alice will add the alert by Friday"). Blame is backward-looking and makes people defensive. Accountability is forward-looking and gives people something useful to do. Blameless post-mortems require accountability -- they do not require the absence of named individuals. **How do you handle systemic post-mortem actions that don't fit in a sprint?** Escalate systemic issues with a concrete ask, not a vague concern. Name the specific gap ("Component X has no owner"), quantify the consequence ("it took 40 minutes to find an investigator"), propose a solution ("assign ownership to Team Y"), assign it to someone at the right organizational level (a named VP or engineering manager), and set a deadline. Framing the issue as a measurable risk gets further than an action item that says "resolve ownership ambiguity." **How do you close a post-mortem properly?** Closing a post-mortem is a conscious act. Either the actions are done, or they are explicitly deprioritized with a documented reason. "We decided not to do this because the risk is low and the effort is high" is a valid outcome. What is not valid is the action quietly rotting in a backlog. Treat post-mortem actions like tech debt: some get done immediately, some get scheduled, and some never get done -- but the "never" should be a deliberate, recorded decision. **How do you motivate engineers to complete post-mortem follow-ups?** The fix is not incentives or penalties. It is making the feedback loop visible. When a follow-up action prevents a future incident, say so publicly -- in the next post-mortem, in the #incident-learning channel, wherever your team shares wins. Engineers complete action items when they see their work matters. The loop is: actions prevent incidents, prevented incidents get noticed, and engineers see that their follow-up work made a difference. ## **About incident.io's Post-Mortem Product** incident.io has launched a [revamped post-mortem product ](https://incident.io/post-mortems)featuring a purpose-built rich editor with incident data woven in, AI drafting from real incident context, real-time collaboration, and Scribe integration that captures debrief calls and brings notes directly into the document. [Get a demo](https://incident.io/demo) to see what is coming.