Postmortem Action Items: How to Make Sure They Get Done
September 17, 2026 · LumifyHub Team
Postmortem Action Items: How to Make Sure They Get Done
Postmortem action items get done when each one leaves the postmortem document and becomes a row in a single table that every postmortem shares, with one owner, a due date and a Done checkbox. Then someone looks at the open rows on a schedule, and at the start of every new postmortem.
Most teams already write good incident reviews. What they lack is a place where the follow-ups can be seen as late. A sentence at the bottom of a document can't be overdue, because nothing about it says when it was due or who it belonged to.
TL;DR: Keep writing the postmortem as a document. Copy every action out of it into one shared actions table: what to do, one owner, a due date, a Done box, and which incident it came from. Sort that table by due date, filter it to what isn't done, and open the next postmortem by reading that list first.
Why postmortem action items don't get done
The pattern is familiar to anyone who has run a few incident reviews. The timeline is honest, the root cause gets found, and near the end the team agrees on a list: add an alert when the disk passes 80%, rotate the logs daily, expire old backups. Everybody reads it and agrees with it. The document is filed.
Three months later the same disk fills up. Someone opens the old review and the alert is right there, written down and never built.
Nobody decided to skip it. The action item was agreed to, which is a different thing from being assigned. A line in a document has a few properties that make it easy to lose:
- It has no owner. "We should add an alert" is owned by the room, and the room goes back to its other work.
- It has no date. Without one, it's never late, so nobody gets asked about it.
- It can't be finished. There's no box to tick, so a finished item and a forgotten one look exactly the same in the document.
- It lives in one review. Each postmortem keeps its own list, so nobody ever sees all the open follow-ups at once, and a repeat of an old fix isn't visible as a repeat.
A founder who built a postmortem tool put the result plainly on Hacker News: they were tired of spending 90 minutes writing postmortems "only for the action items to be forgotten by next week."
The fix: one actions table for every postmortem
Keep the postmortem itself as a document. The narrative, the timeline and the reasoning belong in prose, and a table is a bad place for them. What moves out is the list at the end.
Every action from every review becomes a row in a single table. One table for all incidents matters more than it sounds, because the most useful question you'll ask it is "what have we promised and not done, across everything?"
A postmortem action items template
Copy this structure into whatever tool your team uses for tables:
| Column | Type | What goes in it |
|---|---|---|
| Action | Text | The change, written so someone could start it tomorrow. "Alert when disk passes 80%", not "improve monitoring". |
| Owner | Person | Exactly one person. A team name is how an item ends up owned by nobody. |
| Due | Date | A real date, agreed in the review. |
| Done | Checkbox | Ticked when the change is live, not when a ticket is opened. |
| Incident | Select | Which postmortem it came from, so you can see the actions per incident. |
A few rules make the template work:
- One action per row. "Add alerting and a runbook" is two rows with, likely, two owners.
- Name the owner in the meeting. If nobody will take it, that's a decision worth writing down too, as a row with a note, instead of a quiet omission.
- Pick the due date before the meeting ends. A date set later tends not to get set.
- Link back. Put a link to the postmortem document in the row or the row's page, so the reason travels with the action.
Here's what a small version looks like after three incidents:
| Action | Owner | Due | Done | Incident |
|---|---|---|---|---|
| Alert on login error rate | Sarah | Mar 24 | ✓ | Mar 17 · Login outage |
| One-step rollback for auth | Henry | Apr 3 | ✓ | Mar 17 · Login outage |
| Rotate Postgres logs daily | Sarah | Jun 12 | ✓ | Jun 9 · Disk full |
| Alert when disk passes 80% | Henry | Jun 26 | Jun 9 · Disk full | |
| Alert when disk passes 80% | Sarah | Sep 11 | Sep 8 · Disk full | |
| Move WAL to its own volume | Henry | Sep 18 | Sep 8 · Disk full |
Look at rows four and five. June's review asked for an alert, it was never built, and September's review asked for the same alert again. In a pile of separate documents, nobody would notice. Sorted by due date in one table, the two rows sit next to each other.
Review the open actions before the next postmortem
A table nobody opens is only a tidier document. Two habits turn it into follow-through.
Read the open list at the start of every postmortem. Before anyone writes a timeline for the new incident, filter the table to actions that aren't done and read them out. It takes two minutes, and it's the moment a repeat gets caught: if the new incident is the one an open action was meant to prevent, the review has found its real root cause before it started.
Check the overdue rows on a schedule. Weekly or fortnightly, whichever meeting your team already holds. Sort by due date and ask each owner about anything past its date. The question isn't "why isn't this done?" so much as "is this still the right fix, and is the date still real?" Moving a date is fine. Leaving it silently past is how an action item disappears.
Some items will turn out not to be worth doing. Close them on purpose: tick Done, or delete the row, with a note in the postmortem saying why. An open row that everyone has quietly agreed to ignore teaches the team to ignore the whole table.
This fits the same instinct as a decision log: writing down what the team agreed is only half the job, and the other half is making it findable later by someone who wasn't in the room.
Setting it up in LumifyHub
In LumifyHub the actions table is a database, and the columns above map directly onto property types.
- Create the database from the + beside your workspace in the sidebar and choose Database.
- Use Add property for the columns: a Person property for Owner, a Date for Due, a Checkbox for Done and a Select for Incident. Owner shows the workspace member by name on each row.
- Add a sort on Due, ascending, so the oldest actions come first.
- Add a filter on Done with the condition Is not checked, which leaves only the open actions.
Sorts and filters you add are yours until you choose to share them: a view that nobody has changed doesn't offer to save anything, and once you've changed it, Save for everyone makes that filter part of the view the rest of the team opens. That's the step that turns "my list of open actions" into the list the postmortem starts from.
We've written the setup out step by step, with screenshots, in the guide Run a postmortem your team follows up on.
If your team's incident notes, runbooks and follow-ups are currently spread across several tools, our all-in-one workspace guide covers what it takes to keep docs next to the work. And if the follow-ups you need to chase are status updates rather than fixes, the approach in how to run async standups is a close cousin of this one.
For the wider practice of running blameless reviews, Google's SRE book has a chapter on postmortem culture.
Frequently Asked Questions
What are postmortem action items?
Postmortem action items are the changes a team agrees to make after an incident review so the same failure is less likely, or less damaging, next time. Typical examples are a new alert, a runbook, a rollback step or a configuration change.
Why do postmortem action items get forgotten?
Usually because they stay inside the postmortem document, where they have no single owner, no due date and no way to be marked finished. Nothing about them can look late, so nobody gets asked, and each review's list is only ever seen alongside that one incident.
Who should own a postmortem action item?
One named person per item, agreed in the review. They don't have to do all the work themselves, but they're the one who answers for whether it's done. Assigning an item to a team or "engineering" usually means nobody owns it.
How do you track postmortem action items?
Put every item from every postmortem in one table with an owner, a due date, a Done checkbox and the incident it came from. Sort it by due date, filter it to items that aren't done, and review that view on a schedule and at the start of each new postmortem.
Should postmortem action items go in the issue tracker?
They can, if your team already lives in one and every item becomes a ticket with an owner and a date. What matters is that all the open follow-ups from every incident can be seen together, and that someone reads that list regularly. A ticket buried in a general backlog is only a little better than a line in a document.
What if an action item is no longer worth doing?
Close it deliberately and write down why in the postmortem. A decision not to do something is useful history. An item left open that everyone ignores is not.