Postmortem action items: written well, then abandoned
The postmortem is written and the tickets filed. Six weeks later the same incident class pages you again; the fixes are still in the backlog. This page is a template and a checklist for the part after the document.
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 lose. An item you agreed on and never implemented is a decision to accept the same risk again, made by default. Either it ships or someone accepts that risk on the record.
How Aurora Coach addresses it
Aurora Coach runs the system that outlives the incident: a continuous improvement loop of Sense, Analyze, Recommend, Refine, Commit, Execute, and Re-evaluate. Postmortem follow-through lives mainly in the Operations domain (DORA capabilities as practice), with Workflow (flow, WIP, planning) alongside.
- Sense + Analyze Every team member contributes context: the AI asks structured questions, the team responds. What on-call felt like, which fixes people doubt; Aurora Coach for GitHub adds quantitative signal. The AI synthesizes it into a SWOT and maturity assessment grounded in the team’s actual situation plus industry best practice and research.
- Recommend + Refine + Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote, the team lead refines, the AI never decides. Postmortem actions become commitments owned by the team and tracked through periods.
- Execute + Re-evaluate The team does the work in its own context, alongside delivery. The next period’s analysis sees what changed: progress is visible against previous commitments, and the team keeps pushing or accepts the risk on the record. Context compounds.
Free-text check-ins keep context flowing between incidents. If honesty breaks down in the retro itself, see psychological safety; for the sprint-retro side, retrospective action items.
The action-item template
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 when someone checks status. Items without dates age silently.
The follow-through checklist
The template makes items trackable. This checklist makes them tracked:
- Fixed review cadence, separate from the incident process Open items get reviewed on a recurring cadence the team picks, whether or not there was an incident.
- Aging alerts Any open item past its decision date gets surfaced to the owner and the review.
- Closure requires verification evidence An item closes when its verification method has been run and recorded, not when someone marks it done.
- Recurrence review At an interval the team picks, ask per past incident class: did it recur? Either answer changes what you do next.
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 at the document and the action items go to a backlog where they compete with feature work, and lose. 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.
The template and checklist are yours to lift. A free trial keeps the follow-through running between incidents; MapROI (free, no signup, about 5 minutes) maps the ROI for your on-call reality.