The postmortem was good. Everyone attended, the timeline was accurate, nobody was blamed, and the document ended with nine action items and named owners.
Six months later, two are done, four are in a backlog, two were closed as no longer relevant without anyone checking, and one is the direct cause of the incident you are currently having.
This post is about the part of incident response that happens after everybody has moved on. For whoever writes the postmortems and wonders why the same things recur.
Why the items do not get done
Not carelessness. The structure works against them.
They are created at the moment of maximum motivation and executed at the moment of minimum. In the room, the fix feels urgent. Two weeks later it competes with a roadmap that has not moved to accommodate it.
They belong to nobody's job. The owner is a person, and the work sits outside the objectives their team is measured on. Nothing in their planning process makes room for it.
Many are too big. "Improve our monitoring" is not an action item, it is a topic. It cannot be finished, so it cannot be started.
Nobody tracks them as a set. Individual tickets scatter into individual backlogs and there is no view that says how many incident actions are outstanding across the company, which means nobody can see the trend that would justify time.
Write items that can actually be finished
Three properties, and the third is the one people skip.
Specific enough to be completed, with a definition of done somebody else could verify. Not "review our access controls" but "remove the shared deploy credential and issue per-engineer keys".
Small enough to fit in a sprint. If it does not, split it and accept that only the first part is an incident action. A three-month project that emerged from an incident is a roadmap item, and pretending otherwise means it will be neither.
Classified by what they actually do. This is the distinction that matters:
- Prevent: stops this specific cause recurring.
- Detect: finds it faster next time.
- Mitigate: reduces the damage when it happens again.
A postmortem whose actions are all preventive is usually optimistic, because you cannot prevent everything and the next incident will be a cause you did not anticipate. Detection and mitigation items pay off across incident types, which makes them better value and they are consistently underrepresented.
Give them a deadline proportional to severity
An action from a severe incident with no date is an intention. Tie the deadline to the severity that produced it, agree it in the room while the context is fresh, and treat a missed deadline as something that gets escalated rather than quietly extended.
Then review them on a fixed cadence, as a set, with the people who can reprioritise. Monthly, ten minutes, a single list. The value is not the meeting, it is that the list exists and somebody looks at it.
Track the one number that matters
Completion rate of incident actions, and the age of the oldest open one.
If the completion rate is low, you have a system that produces good analysis and no change, which is worse than it sounds because the analysis creates a documented record that you knew. An unfixed action item from a postmortem is the most difficult artefact to explain after a repeat incident, to a customer, an auditor, or a regulator.
Also watch for repeat causes. The same cause appearing twice means the first postmortem's actions did not address it, and that is a finding about your process rather than about the system.
Close items honestly
Three legitimate outcomes, and only one of them is "done".
Done, with evidence. A link to the change, not an assertion.
Won't do, with a reason and a named person accepting the risk. This is a perfectly good outcome and it needs to be recorded as a decision rather than achieved by silence, because it is the same thing as a risk acceptance and deserves the same expiry.
Superseded, when something else solved it. Verify that it actually did.
What corrodes the practice is the fourth, unofficial outcome: closed because it is old and nobody remembers. That converts your incident record into a document that says you identified a problem and implies you fixed it.
Make the work legitimate
The durable fix is not discipline, it is capacity. Teams that complete these have an explicit allocation, whether that is a percentage of each sprint, a rotating engineer on reliability work, or a standing agreement that incident actions enter the next sprint before feature work is planned.
Without an allocation, every action item is a negotiation between a named individual and their own roadmap, and that negotiation has a predictable outcome.
The concession
Not every action item deserves completion. Some are written in the emotional aftermath of a bad night and are disproportionate to a cause that will not recur. Insisting on a hundred percent completion rate produces items written defensively, or a backlog nobody believes in.
So the honest target is not completion, it is resolution: every item reaches one of the three states above, with a decision recorded. A postmortem where four items were done and five were explicitly declined with reasons is a healthier artefact than one where all nine are open and everyone has stopped looking.
The implication
The postmortem is not the output of an incident. The changes are, and the document is a plan for making them.
Which means the quality of your incident process is measured months later, by whether anything is different, and the only way to know is to keep the list and look at it.
