A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent recurrence, per Google’s SRE Book. The same chapter states the primary goals plainly: document the incident, understand the contributing causes, and — especially — put effective preventive actions in place. The document is not the deliverable. The closed, verified action item is.
For a team of two to fifteen engineers who are their own on-call rotation, the failure is rarely in the writing. It is in the handoff. During the incident, there was an incident commander, a timeline, and a resolution. The action item that replaces it enters a backlog with no owner, no date, and no definition of done, while feature work enters with all three. Losing that prioritization contest is the default, not a discipline failure.
The gap is structural, not cultural
Google’s SRE Workbook, in its postmortem culture chapter, walks through a deliberately bad postmortem and names the failure modes. The action items are mostly mitigative; the one “preventative” item suggests making humans less error-prone, which the chapter says is less reliable than changing automated systems and processes. Two items use vague language — “Improve” and “Make better” — which the chapter says makes success criteria hard to measure. Only one item was assigned a tracking bug, and the chapter notes that without a formal tracking process, action items from postmortems are often forgotten, resulting in outages.
The same chapter quotes Ben Treynor Sloss: “To our users, a postmortem without subsequent action is indistinguishable from no postmortem.” It also states that action items without clear owners are less likely to be resolved, and that a single owner with multiple collaborators beats shared ownership. That is the whole argument in two sentences. The rest is mechanics.
Atlassian’s incident postmortem guide makes the same point from the planning side: findings should feed back into the planning process so remediation work is prioritized alongside other work. It also says an unreviewed postmortem “might as well never have been written.” Review is necessary but not sufficient. An item can be reviewed, approved, and still rot.
Two failure modes that let items rot
Owner: “the platform team.” A team is not an owner. A team is a distribution list. When the item is due and nothing has happened, there is no name to ask. The Google Workbook’s guidance is explicit: one owner, multiple collaborators. The named owner does not have to do most of the work. The name exists so that escalation has an address.
Done: “merged.” A merged pull request proves code changed. It does not prove the change would have caught the incident. The distinction matters most for detection items — a new alert that fires in staging but pages nobody in production is merged and useless. Verification has to be chosen when the item is filed, while the person who wrote it still remembers what would have caught the failure.
The five-field action item
Every item needs five fields. If one is hard to fill in, the item is not ready to leave the postmortem meeting. This is a recommendation, not a published standard; it borrows the actionable/specific/bounded framing that PagerDuty’s postmortem writing guide attributes to Google’s Lunney, Lueder, and Beyer, and adds a verification field because “bounded” alone does not say how you will know it worked.
- Classification. Guardrail (prevents the failure), detection (catches it sooner), process (changes how people respond), or knowledge (spreads what one person learned). The class determines what verification looks like.
- One named owner. A person, not a team. Collaborators are listed separately.
- Smallest shippable version. The version that could merge this sprint. A rate limit on one endpoint, not “redesign the throttling layer.” Large items get split, not deferred.
- 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 it is filed. Default to the end of the next sprint for guardrail and detection changes. Anything further out needs the reason written beside the date.
PagerDuty’s postmortem template shows a lighter version of the same discipline: each action item is a JIRA ticket tagged with the incident date and severity so it can be found and reported later. The tag is the trigger. Without it, the item is a sentence in a document that nobody queries.
A review cadence that is not the incident process
The incident process ends when the postmortem is published. If follow-through depends on the next incident to prompt a review, the cadence is set by outages. That is the wrong clock.
For a small team, the cheapest structural fix is not new tooling. It is a recurring fifteen-minute review attached to a meeting that already exists — the weekly ops sync, the sprint planning opener, the Monday standup that already runs long. The agenda is one filtered list: open action items past their decision date, sorted oldest first, with the owner’s name on each row. A saved filter on the due-date field does this in Jira, GitHub Issues, or Linear without a new system.
Two rules keep the meeting short. Aging items go first, not newest. And an item that has slipped twice gets either a new date with a written reason or an explicit decision to drop it and accept the risk. Silent slippage is how a backlog becomes a graveyard.
Closure on evidence, not on a status field
An 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. This is stricter than most small teams operate, and it is the step that prevents the “said it was done, nothing actually happened” failure.
For knowledge items — a runbook update, a decision record — verification is a review by someone who was not on the incident. If the runbook cannot be followed by a teammate who was not there, it is not done. This connects directly to the practice of writing the recovery checklist before you need it; the Recovery Checklist article covers the document side of the same problem.
A quarterly recurrence review
Once a quarter, list the incident classes from the previous 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 category of fix is worth repeating. This is the feedback loop on the action-item process itself, and it is the only way to learn whether your guardrails or your detection changes are actually buying reliability.
The Google Workbook’s rack-decommission case study is a useful reference point here. Three years after the original outage, a similar incident occurred, and the chapter states that the action items implemented from the original postmortem dramatically reduced the blast radius and rate of the second incident. That is what a shipped, verified fix looks like from the outside: the same class of failure returns smaller.
A worked hypothetical for a small team
The following is a constructed example, not a real incident record. It illustrates how the five fields change what happens after the third postmortem.
A six-person platform team runs a webhook delivery queue. It overflows three times in a year. Each incident gets a competent postmortem. The first two produce action items like “improve queue monitoring” and “add backpressure,” owned by “the platform team,” with no date. Neither ships. The third postmortem opens with an engineer copying from the first.
Under the five-field format, the third postmortem produces three items instead:
- Detection: alert when queue depth exceeds 80% of the worker pool’s drain rate for five minutes. Owner: one named engineer. Verification: replay the prior incident’s traffic pattern in staging and confirm the alert fires. Decision date: end of next sprint.
- Guardrail: per-tenant rate limit on webhook enqueue. Owner: a second named engineer. Verification: load test at 3x peak with one tenant saturated; confirm other tenants’ delivery latency stays within SLO. Decision date: two sprints out, with the reason written beside it.
- Knowledge: runbook section for queue saturation, including the drain command and the escalation path. Owner: the on-call engineer who worked the incident. Verification: a teammate who was not on the incident follows the runbook in staging without help. Decision date: one week.
The difference is not effort. It is that each item now has an address, a date, and a test that can fail. The weekly review surfaces the rate-limit item when it slips. The quarterly recurrence review asks whether the queue class returned after the alert shipped. If it did, the detection fix was the wrong category, and the next postmortem should say so.
What this costs a lean team
Fifteen minutes a week, one saved filter, and the discipline to refuse an action item that has no owner or no verification. The tradeoff is real: some items will be dropped rather than carried indefinitely, and dropping them is an explicit risk decision that should be recorded. That is cheaper than a backlog of items nobody believes will ship, and it is the only version of follow-through that survives a team with no dedicated reliability staff.
FAQ
What should a postmortem action item include?
A classification, one 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 against feature work. The fix is structural: a recurring review outside the incident process, aging surfaced first, and closure on verification evidence.
Doesn’t a named owner conflict with blameless postmortems?
No. Blamelessness is about how the incident is analyzed — focusing on contributing causes rather than indicting individuals. Ownership is about who carries the follow-up work. The Google Workbook treats these as separate concerns and recommends a single owner with collaborators for each action item.
Do we need a new tool?
Usually not. A saved filter on the due-date field in whatever tracker you already use is enough to run the weekly review. The failure mode is not tooling; it is the absence of a cadence and the absence of a verification field.