Action Items: The Part of Post-Mortems Nobody Gets Right

Your team ran a post-mortem last Tuesday. You wrote six action items. By now, maybe two have Jira tickets. One has an owner who is currently on a different fire. Three are still in the Google Doc, under the heading "Follow-ups", untouched.

Action items are where post-mortems either pay out or perform. Most do the latter. Research from incident.io puts the completion rate below 50% for the median SRE team. That means the average post-mortem produces about as much change as a retrospective sticker vote -- the process runs, the blame stays blameless, and the same failure mode ships again six weeks later.

The fix is not a better template. It is a different understanding of what makes an action item real.

Why Most Action Items Are Structurally Broken

Writing "improve monitoring" in a post-mortem feels productive. It is not an action item -- it is a category of work with no owner, no deadline, and no definition of done.

Effective action items have three irreducible parts: what needs to be done (specific and measurable), who owns it (a named engineer, not a team), and by when (a specific date, not "Q3"). Missing any one part means the item is unlikely to close, because fictional items do not get deprioritized -- they dissolve. Nobody actively decides not to do them. They simply never surface in the places where work actually gets scheduled.

The distinction is sharper than it sounds. "Improve rate limiting" is fiction. "Add a circuit breaker on upstream search API calls in the checkout path -- owned by @anya, target: merged by 2026-09-19" is an action item. One will show up in a standup. The other will not.

The structural failure happens at the moment of writing, when engineers are tired, the meeting is running long, and the pressure to wrap up is higher than the pressure to be precise. That is exactly when precision matters most -- because context degrades fast, and the detail you skip at 11pm is the detail @anya will need to ask about in three weeks.

The Number That Should Bother Every Team Lead

Over 50% of post-mortem action items are never completed across typical SRE teams. At organizations with weak incident cultures, that number climbs past 70%.

Consider what that means for reliability at scale. If your post-mortems average four action items per incident and you run ten incidents per quarter, you are generating 40 items, completing fewer than 20, and carrying a growing backlog of unfixed failure modes. The next incident is statistically likely to be a variant of something you already diagnosed.

DORA research consistently finds that high-performing engineering organizations have lower change failure rates not because they write better post-mortems but because they close their action items. The document is not the work. The ticket is the work.

When completion rates drop below 50%, post-mortems become theater -- written to satisfy a process, not to change anything. The team knows it. The engineers who do write careful items watch them rot. Eventually, the quality of items written degrades to match the completion rate. Why write a precise, ownable item if nobody closes the ones that already exist?

Mitigative and Preventative Are Not the Same Queue

Post-mortem action items split into two categories, and treating them identically is a planning mistake that compounds over time.

Mitigative items reduce the blast radius of the next occurrence before you have eliminated the root cause. Add a fallback. Set a timeout. Wire a circuit breaker. These items are almost always urgent and should ship within one sprint -- ideally before the post-mortem meeting closes if they are small enough.

Preventative items remove the failure mode entirely: refactor the queue consumer, redesign the retry logic, instrument the SLO gap that let this slip past your burn rate alert. These take longer, require design review, and compete directly with feature work.

Mixing both in a single "post-mortem actions" label means the long preventative items drag on the list long enough for the team to forget why they were written, while the mitigative items wait in the same queue behind them. Separate them explicitly. Mitigative items go into the current sprint before planning closes. Preventative items get sized and prioritized against your roadmap on their own schedule -- treated like any other reliability investment, not like post-it notes attached to an incident that is already closed.

Where Action Items Go to Die

The Google Doc is the most common graveyard.

Teams draft post-mortems in shared documents because docs are low-friction during an incident. The problem is that the doc is not where engineering work lives. Jira is. Linear is. GitHub Issues is. Wherever your sprint planning happens -- that is where an action item needs to land before the post-mortem meeting ends.

The integration gap is the most predictable failure point in the entire workflow. Incident occurs. Post-mortem runs. Good action items get written. Then somebody has to manually copy them into a ticket system. That copy step has a completion rate of roughly 40% in teams that do not automate or enforce it.

The fix is not a new tool -- it is removing the gap between the post-mortem document and the sprint system. Several incident management platforms now write Jira or Linear tickets directly from post-mortem templates. Note-taking tools that generate structured items with owners and integrate with your tracker serve the same function. The key principle is that no engineer should be copy-pasting from a doc into a ticket after a 90-minute review meeting at the end of an on-call shift.

Meetings That Capture Action Items Before They Evaporate

One underrated problem: the action items that get written in a post-mortem meeting are not always the ones that end up in the document.

In a room of four engineers decompressing from a rough incident, the most important items often surface conversationally before anyone has opened a laptop. "We should have caught that in the canary" -- is that an action item? Depends who heard it, whether they wrote it down, and whether the meeting facilitator remembered to ask at the close.

The facilitator role in a post-mortem is harder than it looks. You are managing group dynamics, keeping the timeline honest, watching the room for attribution drift, and simultaneously supposed to be capturing every follow-up that surfaces. Something slips. It is not negligence; it is cognitive load.

AI note-taking tools that run in the background and surface structured items from meeting transcripts have become a practical fix for this problem. Not because they are smarter than engineers, but because they are not tired, not managing the room, and not context-switching between facilitating and documenting. The output still needs human review. But having a first-pass draft of items from the full conversation -- including the offhand comment at the 45-minute mark -- changes what survives the meeting.

The Owner Problem: Teams Do Not Complete Tasks

Assigning an action item to a team is the organizational equivalent of assigning it to nobody.

Teams do not have calendar reminders. They do not get flagged in Jira. They do not show up in a standup when an item is overdue. "The platform team" does not have a notification inbox. @carlos does.

Named owners matter, but named owners with context matter more. "Fix the queue consumer" assigned to @carlos is better than nothing. "@carlos: add exponential backoff to the SQS consumer in payments-worker -- see incident timeline for the burst pattern that hit at 14:23 UTC. Target: merged before 2026-09-26 sprint close, Jira: PAY-2891" is something @carlos can execute without a follow-up conversation.

The post-mortem is the moment when context is highest. That is when you write the item. The detail degrades fast -- within 48 hours, half the room has forgotten the specific burst pattern that triggered the failure. Within two weeks, the incident is background noise. The item written with full context at the end of the post-mortem meeting is the one that gets closed. The item that gets "we'll write it up properly later" gets orphaned.

Observability Gaps Are a Special Case

A significant fraction of post-mortem action items involve observability gaps: a metric that was not instrumented, an alert threshold that was too loose, a dashboard that existed but was not linked from the runbook, an SLO window that was too wide to catch the degradation before users noticed.

These items have a predictable failure pattern. They require access to your monitoring stack. They are not urgent once the incident is closed and the immediate fire is out. And they tend to require coordination between the product team that hit the incident and the platform team that owns observability tooling -- a handoff point that often means nobody formally owns the closure.

The fix is to treat observability action items as a first-class category with a direct owner on the platform team, not the product team that hit the incident. "Add p99 latency alert on search-service checkout path" should have an owner in your observability platform -- someone who actually has the access and context to write the alert rule -- not a product engineer who will have to ask three questions before they can start.

Closing the Feedback Loop Nobody Closes

There is a step after completion that most teams skip entirely: acknowledging it.

When an action item from post-mortem #47 prevents the recurrence that would have become incident #58, that connection should be made visible. Write it in your incident channel. Put it in the next all-hands engineering update. Let the on-call engineer who owned PAY-2891 know that their circuit breaker absorbed a burst last Thursday and nothing paged.

Engineering teams complete more action items when they see their work paying off. Teams that write items into a doc that nobody revisits eventually stop writing them seriously -- the format remains, but the quality drops to match the perceived impact. That is how a blameless post-mortem culture can still produce a reliability culture with no memory.

The feedback loop is what separates post-mortem cultures that improve from those that perform. At 3am, the on-call engineer who fixed a timeout last quarter because of an item they owned -- that engineer knows exactly what the work was for. Make that connection explicit for the whole team, not just the person who happened to be on-call when the fix proved its value.

What a Working Action Item Looks Like

Here is the format that consistently closes:

Item: Add circuit breaker on search-service upstream calls (payments path)
Owner: @danielle
Type: mitigative
Due: 2026-09-12 (before next deploy to prod)
Ticket: PAY-2891
Context: search-service timeouts caused cascading failure in checkout at 14:23 UTC;
circuit breaker limits blast radius on next occurrence while refactor is scoped

Seven fields. The "Context" field is not optional. It is what survives the three-week gap between the post-mortem and the sprint where @danielle finally has bandwidth. Without it, the item is a task with no story. With it, @danielle can open PAY-2891 cold and know exactly what she is building and why it matters.

What This Requires From the Engineering Lead

Action item completion is a team lead metric, not an engineer metric.

The engineers write the items. The lead is responsible for the system that ensures they close. Concretely, that means four things:

First, sprint capacity allocated for mitigative items before planning starts -- not after the team has committed their velocity to feature work. If mitigative items have to compete for scraps, they lose.

Second, a standing five-minute review of open post-mortem items at the weekly team sync. Not a ceremony. Just a scan: anything older than 14 days that is not in a ticket, anything overdue that needs a decision.

Third, explicit deprioritization when something genuinely cannot be done. "We are not doing PAY-2891 this quarter because the payments refactor ships in Q4 and this becomes redundant" is a decision. "PAY-2891 has been in the backlog for three months" is a failure of process.

Fourth, tracking action item completion rate as a team health metric alongside deployment frequency and MTTR. Teams that measure it find it averages around 42% without deliberate process. With named owners, sprint integration, and a weekly review, that number climbs above 75% within two quarters. The difference in reliability terms is roughly equivalent to preventing one additional major incident per quarter for a team running at a ten-incident cadence.

The post-mortem told you what broke. The action item is the contract to fix it. Whether that contract closes is a management decision, not a document quality problem.