Six months ago, a batch job silently dropped a handful of end-of-day trade confirmations. The postmortem was thorough. It had a timeline, a root cause, and four action items with owners and due dates. Everyone signed off. Two weeks ago, the same batch job dropped confirmations again — different day, same silent failure mode, same root cause the document had already named.
Nobody was surprised. That's the part worth sitting with.
The Document Everyone Signs, Nobody Owns
A postmortem is easy to produce and hard to enforce. Writing it is a few hours of structured reflection. Acting on it is a commitment against next sprint's roadmap, made by someone who usually isn't in the room when the roadmap gets prioritized. The document gets approved. The action items get filed. And then the postmortem's authority quietly expires the moment the meeting ends, because nothing in most engineering organizations actually tracks whether "fix the batch job's failure handling" happened, only whether it got a ticket number.
That's not a discipline problem. It's a design problem — the postmortem process has no mechanism that outlives the meeting.
Why Action Items Die
Three patterns show up over and over in the incidents I've supported:
No owner survives a reorg. The engineer who owned the action item changes teams, and the item becomes an orphan in someone else's backlog, deprioritized by a person who wasn't at the incident and doesn't feel its weight.
Remediation competes with a roadmap that doesn't know it exists. Feature work has a stakeholder pushing for it every week. A postmortem action item has a stakeholder who shows up once, at the retro, and then goes quiet until the incident recurs.
"Low severity" is doing a lot of work it shouldn't. An incident gets labeled low-impact because this time the blast radius was small — a few dozen records, an off-peak window, no client called. The severity label follows the impact of the last occurrence, not the risk of the next one, so the same failure mode keeps getting re-triaged as low priority right up until the day it isn't.
The Recurrence Tax
The cost of a recurring incident isn't just the second outage. It's what happens to the team that watched it happen twice. The on-call engineer who flags "this is the same thing as last time" and gets told the fix is still in the backlog stops flagging it with urgency the third time. Production support engineers are usually the first to notice a pattern repeating, because they're the ones paged for it — and when that observation doesn't change anything, the rational response is to stop treating the postmortem as a real commitment and start treating it as paperwork. That's a more expensive loss than the recurring incident itself: it's the erosion of the one feedback loop that was supposed to make the system safer over time.
What "Done" Actually Requires
Google's SRE postmortem culture guidance is explicit that a postmortem's action items need assigned owners and due dates as part of the artifact itself, not as an afterthought bolted on in a follow-up meeting (sre.google/workbook/postmortem-culture). That's a necessary condition, but in practice it's not sufficient — an owner and a due date only matter if something outside the document enforces them once the due date passes quietly. The organizations that actually close the loop tend to add one more thing: a review cadence that isn't optional, where open action items get reported on whether or not anyone asks.
Treat Remediation Like Debt You Can See
The pattern that's worked best on my team: postmortem action items don't go into the general backlog. They go into a separate, small, visibly-aging list — the same instinct as a technical debt register, but scoped to promises made under incident pressure. Every item carries the date it was created, and once it crosses a threshold (30 days for anything tied to a Sev-1 or Sev-2), it escalates automatically to whoever owns the roadmap, not the engineer who happens to still remember the incident. The point isn't process for its own sake — it's making the cost of not fixing something visible to the person who has the power to reprioritize, instead of leaving that cost invisible until the pager goes off again.
The Role Production Support Actually Plays Here
Production support engineers are usually the ones who notice recurrence first, because they're the ones who feel it first. That makes them the natural owners of the aging list above — not because they should be doing the remediation work themselves, but because they're the people best positioned to say, credibly, "we already wrote this down once." Turning that observation into an escalation with teeth, instead of a comment in a Slack thread that scrolls away, is most of what separates a postmortem process that improves the system from one that just documents its failures.
A postmortem that doesn't outlive its meeting isn't a safety net. It's a record of what you knew before it happened again.