Postmortem action items: from backlog tickets to shipped fixes
Teams write the postmortem, agree the action items, and file them. Then the items sit. This page has the action-item template and the follow-through checklist, free to copy. At the bottom, a team whose same queue overflowed three times in a year runs the loop that finally ships the fix.
The solved half and the unsolved half
The writing half is mature, most canonically in the Google SRE book’s postmortem culture chapter. Then the process ends. Action items go to a backlog where they compete with feature work and SLA commitments, and they rarely win.
The incident had an owner and a deadline. The backlog item that replaces it has neither.
A postmortem nobody implements is a well-written record of what will happen again.
The action-item template, free
A postmortem action item needs five fields. If one is hard to fill in, the item is not ready yet.
- Classification Guardrail (prevents the failure), detection (catches it sooner), process (changes how people respond), or knowledge (spreads what one person learned).
- Owner One named person, not a team. "Platform team" is how an item becomes nobody’s job.
- Smallest shippable version The version that could merge this sprint. A rate limit on one endpoint, not "redesign the throttling layer".
- Verification method How you will know it would have caught the incident: replay the trigger, inject the fault, or point at the alert that now fires. "Merged" is not verification.
- Decision date A calendar date, written on the item the day you file it. Default to the end of the next sprint for a guardrail or a detection change; anything further out needs the reason written down beside it.
The follow-through checklist
The template makes items trackable. This checklist makes them tracked:
- A review cadence that is not the incident process Open items get reviewed on a fixed schedule whether or not anything broke that month. Monthly covers most teams, weekly once you are past about ten open items. Attach it to a meeting that already exists. The same failure mode outside incidents is retrospective action items.
- Aging surfaced, not remembered Anything past its decision date goes to the top of the next review with its owner named. A saved filter on the due-date field does this; no new tooling required.
- Closure on evidence, not on a status field The item closes when the verification method has been run and the result is recorded on the item: the replay output, the alert that fired, a link to the new test. Marking it done is not closing it.
- Recurrence review, once a quarter List the incident classes from the last four quarters and mark each one recurred or did not. A recurrence means the fix was wrong or never shipped. No recurrence tells you which kind of fix is worth repeating.
What should a postmortem action item include?
Five fields: a classification (guardrail, detection, process, or knowledge), a single named owner, the smallest shippable version of the fix, a verification method, and a decision date. An item missing an owner or a date is a suggestion, not an action item.
Why do postmortem action items never get done?
Because the incident process ends when the document is published, and implementation then depends on backlog prioritization, where action items rarely win. The fix is structural: a recurring review outside the incident process, aging alerts, and closure on verification evidence.
What is a blameless postmortem?
A postmortem that focuses on contributing causes without blaming individuals, on the premise that people acted reasonably given what they knew. Described in the Google SRE book’s chapter on postmortem culture. Blamelessness solved writing; follow-through is the problem that remains.
From filed to fixed: a worked example
Simulated team · Real product output Harborline Systems, a fictional B2B infrastructure company on 24/7 hosting SLAs. Six people on the platform team, and the same carrier-webhook queue overflowing three times in one year. Each incident got a good postmortem. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Every team member answers structured questions in their own words, and can take any thread further with the coach in a check-in. Those sessions roll up into one analysis of the team.
Writing the same postmortem twice
In April the engineer opened January's document and copied from it. January's action items were all still open: about a week of work in total. The question that followed: what is the point of a process where the document is the only deliverable? The coach names it back, verbatim: “the postmortem process has become performative theater instead of actual learning and improvement.”
The team lead asks for the structure
A second check-in, a different person, the same gap from the other side. Three things, per the coach: a review that tracks items across postmortems rather than one incident at a time, ownership at a level that can allocate capacity, and a forcing function. The coach's words: “we don't close the postmortem until action items are either completed or leadership explicitly accepts the risk of deferring them.”
2Recommend, refine, commit
What the postmortems kept concluding and the backlog kept burying comes back as a suggestion the team votes on and commits to. The AI informs the decision, it does not make it.
The same idea, written for one team
The title arrived unprompted: owners and a weekly review. Four action steps, a two-week timeframe, and a success metric that closes the loop this page is about, “reduction in repeat incidents caused by previously identified root causes.” Now read the Context and Relevance fields. They argue from Harborline's own situation: the blameless reviews are already good here, so the gap is prioritization and visibility rather than culture, and a team this safe to speak in is the kind that slides into review fatigue when nothing follows. The checklist above would have told this team to assign owners; it could not have told them their culture was fine and their backlog was the problem.
3Execute and re-evaluate
The team does the work in its own context, and the next period's analysis shows progress against what was committed and whether the incident class came back. Harborline has run one period; the recurrence view starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the template and checklist above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.