✅ Writing (and Tracking) Effective Postmortem Action Items

A postmortem’s timeline, root cause, and impact all exist to produce one thing: action items that make the next incident less likely or less painful. Everything else is analysis. The action items are the only part that changes the future — and they’re the part teams get wrong most consistently. This guide is about writing items that actually ship and tracking them so they don’t quietly die.

Why action items die

Watch a batch of postmortem action items over a quarter and you’ll see the same causes of death:

• Too vague to start. “Improve monitoring” has no first step, so it never gets one.
• Owned by a team, not a person. “Platform will look into it” means nobody will.
• No due date. Work with no deadline loses every priority contest against work that has one.
• Never left the doc. Written in the postmortem, never filed as a ticket, invisible to sprint planning.
• Too big to fit a sprint. “Rearchitect the deploy pipeline” is a project, not an action item, and it stalls.

Fix these five and your completion rate climbs dramatically. None of them is about effort; they’re about how the item is written and where it lives.

The anatomy of an item that ships

Every action item should have five attributes. If it’s missing one, it’s not ready.

1. Specific and testable. Not “improve alerting” but “add an alert on checkout p99 latency > 800ms sustained for 2 minutes.” You should be able to tell unambiguously when it’s done.
2. Owned by one named person. They don’t have to do all the work, but they own getting it to done.
3. Tracked in your real system. A ticket in the same backlog as everything else, linked from the postmortem. If it’s not in the tracker, it doesn’t exist.
4. Dated. A due date proportional to severity. High-severity findings get near-term dates; nice-to-haves get honest longer ones.
5. Classified by type. Prevent, detect, or mitigate. This one deserves its own section.

Classify every item: prevent, detect, mitigate

Tag each action item with what it does:

• Prevent — stops this class of incident from happening again (a validation step, a guardrail, a test).
• Detect — finds it faster next time (an alert, a dashboard, a synthetic check).
• Mitigate — reduces blast radius when it does happen (a circuit breaker, a faster rollback, a timeout).

Now look at the distribution. If every item is “prevent” and there are zero “detect” items, you’re betting you can eliminate all future failures — and you’ll be just as blind when the next unforeseen one slips through. Healthy postmortems produce a spread. You can’t prevent everything, so you invest in detecting and surviving what you miss.

A tracking table you can paste in

Put this at the bottom of every postmortem and mirror it into your tracker:

## Action items
| # | Action item                              | Owner | Type     | Priority | Ticket   | Due    | Status |
|---|------------------------------------------|-------|----------|----------|----------|--------|--------|
| 1 | Block locking migrations in pre-deploy CI| A. R. | Prevent  | P1       | JIRA-101 | 07-25  | Open   |
| 2 | Alert on orders p99 > 800ms for 2m       | B. K. | Detect   | P1       | JIRA-102 | 07-20  | Open   |
| 3 | Add statement_timeout to all migrations  | C. L. | Mitigate | P2       | JIRA-103 | 07-30  | Open   |
| 4 | Update pool-exhaustion runbook           | D. M. | Mitigate | P3       | JIRA-104 | 08-10  | Open   |

The columns aren’t decoration. Owner and due date drive accountability, Type reveals gaps in your strategy, Priority lets planning slot them honestly, and Ticket makes them real.

Tracking them to done

Writing good items is half the job. The other half is a closing loop, because even well-formed items rot if nobody looks at them again.

• File before you close the postmortem. The postmortem isn’t “final” until every item is a ticket. Make this a hard rule.
• Review open items in a recurring forum. A short standing agenda item — a weekly reliability sync or a monthly review — where someone reads out overdue postmortem action items. Sunlight kills procrastination.
• Track a completion rate. What fraction of last quarter’s action items shipped? If it’s under half, your postmortems are producing documents, not change, and that’s a process problem worth its own discussion.
• Escalate the stuck ones. An item overdue by weeks is either mis-prioritized or blocked. Either way it needs a decision — reprioritize, resize, or explicitly drop it. What you must not do is let it sit “open” forever, silently.

Common mistakes

• Turning findings into a project. “Rewrite the deploy system” is a program of work. Break the postmortem’s contribution into a shippable first step.
• Over-generating items. Fifteen action items from one incident means none will get real attention. Pick the three or four that matter and be honest about the rest.
• Assigning to the responder by default. The person who fought the fire isn’t automatically the right owner for the fix. Assign by who’s best placed, not who was on-call.
• “Investigate X” as an action item. Investigation is fine, but it must produce a decision with a date, or it becomes an open-ended hole.

Wrapping up

Action items are the only part of a postmortem that changes anything. Write them specific, owned, tracked, dated, and classified by prevent/detect/mitigate. Then close the loop: file them before the doc is done, review the open ones on a schedule, and measure your completion rate. A team that ships its action items stops seeing the same contributing factor cause a second incident — which is the whole reason you wrote the postmortem.

Related

• Postmortem Action Items That Never Ship
• Turning a Postmortem Into Action Items With AI
• Running Incident Retrospectives: A Facilitator’s Template