The post-incident action item tracker: where fixes live after the post-mortem ends

The post-mortem is not where incidents get fixed — it is where fixes get promised. The real failure point is the two weeks that follow, when the meeting's energy evaporates, the action list scatters across a doc, a ticket queue, and two people's memories, and by the next incident the same root cause walks in the door wearing a different hat. A blameless review with 100% attendance and a beautifully honest cause chain still produces nothing if its output is a list nobody owns. The post-mortem template defines the report; this page defines the system that lives after it: one table, one owner per row, evidence-based closure, and a weekly sweep short enough that it never gets skipped.

The tracker exists to answer one question at any moment: which of the guards we promised after past incidents are actually running in production right now? Not “which tasks are done” — which risks are reduced. Those are different questions, and the gap between their answers is where repeat incidents are born.

1. One table, one owner

All incident actions live in one table, wherever your team already works (a spreadsheet is fine — the tool is not the failure mode). One person owns the table: usually the ops or engineering lead. Not the incident commander, who rotates; the table owner is stable, because the tracker's whole value is continuity across incidents. Every action from every post-mortem lands in the same table within 24 hours of the review. The moment a second list exists — a personal doc, a channel pin, a “remind me” — you have two trackers, and two trackers means zero trackers, because each one assumes the other is watching.

Size expectation: a healthy small team accumulates roughly two to five open actions per incident. If a post-mortem produces fifteen, the review did not converge — it inventoried. Cap new actions at five per incident and force ranking: which three, if shipped this quarter, would have cut this incident's detection or recovery time the most?

2. Row anatomy

3. Action statements: verbs that change systems

A good action names a thing that will exist afterward that did not exist before: an alert, a guard, a checklist line, a runbook step, a config default, a test. “Add a queue-depth alert at 80% that pages on-call” is an action. The two fake verbs that fill real trackers:

• “Investigate X” — investigating is already someone's job; it closes the moment curiosity does. If investigation is genuinely needed first, the action is the artifact it must produce: “Investigate and file: a written proposal for X, due [date], to be turned into a new action row.”
• “Consider/look into” — a verb with no deliverable and no failure state. Nothing can ever prove you failed to consider something. Ban it.

Test every new row with one question: if this row were closed, what is physically different in the system? If the answer is “we understand it better,” rewrite the row or kill it. This discipline pairs naturally with the six-numbers review in the incident metrics report — the metrics tell you which number moved; the tracker holds the changes that moved it.

4. The closure gate: done is not risk reduced

An action closes only on verification evidence, and the evidence standard is “a skeptical newcomer could click the link and see the change.” That means: a merged PR, not a written-up plan; a screenshot of the new alert firing in staging, not a promise that it will; the runbook section as it now reads, not the intent to update it. The three legitimate closures:

• Guard shipped — the change is live (link the merge, the config, the alert rule).
• Guard tested — the guard works (link the drill result, the fired alert, the restored-from-backup screenshot; a restore drill is the model: an untested backup is a rumor).
• Risk consciously accepted — with a one-line reason and a named accepter. “Not worth the build cost at our scale; revisit at 50 customers” is a legitimate, honest close.

“Task done” — someone wrote the doc but nobody adopted it, someone built the alert but it never fires — does not close a row. This is the difference between closure rate as a vanity number and closure rate as a safety number.

5. The weekly ten-minute sweep

Same slot every week, ten minutes, hard stop, and the agenda is fixed so it never needs preparation:

Ten minutes works only because the tracker is one table with four statuses. The moment the sweep needs “prep,” it starts skipping weeks, and three skipped weeks is a dead tracker.

6. The kill rule and the re-open rule

Kill rule: an action with no named owner after its second sweep is KILLED — not carried, not re-triaged. A row that two consecutive weekly sweeps could not get an owner for has told you something true: nobody believes it matters enough. Record the kill with one line of reasoning in the row; it can be re-raised any time with a named owner.

Re-open rule: if the same root cause recurs, every CLOSED action linked to that cause from the earlier incident is automatically REOPENED. This is the tracker's self-audit: a recurrence proves one of two things — either the action was fake (closed on “done”, not on evidence), or it was real but insufficient. Both findings matter, and the blameless review of the new incident starts from that list instead of from a blank page. Re-opened actions get a fresh owner, a new date, and a harder evidence bar, because the first bar already failed once.

7. Worked example: six incidents, one quarter

A twelve-person payments SaaS, tracking actions in one spreadsheet with a Friday 09:30 sweep. Quarter start: eleven open actions, three without owners, closure rate 40%, median age 46 days. Quarter end: closure rate 83% (the honest band — the remaining 17% are two large migrations with real due dates, and the team explicitly rejected the 100% reading as sandbagged), median age 19 days, one re-open. The queue-depth alert from action #7, closed in week three with a screenshot of it firing in staging, cut MTTD from 31 to 9 minutes and was cited by name in the quarterly metrics report — the first time a number in the report traced to a specific tracked action. One incident recurred (config drift); its two previously closed actions re-opened automatically, and the review found the original evidence had been a written plan with no merge — a fake closure, now visible. The sweep's biggest fight was the kill rule: two actions died in week six and one owner fought it, then shipped a better-scoped version with a real owner two weeks later.

8. Metrics for the tracker

• Action closure rate — closed with evidence / total. The honest band is 70–85%. Under 70%: the sweep is not happening or owners are fictitious. 100%: you are accepting everything or sandbagging the due dates.
• Median action age — creation to evidence-closure. Under 30 days; growing age means actions are too big — split them.
• Re-open rate — re-opened / closed. Under 10%. Above that, your closure evidence standard is fake and the tracker is selling you comfort.
• Overdue count — visible every sweep, in bold, with the trend. This is the number that keeps the ten minutes honest.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit Vol. 2 — advanced incident response & communications, including the post-mortem pack — $27
• Ops Mega Bundle — all 5 kits in one download — $29
• Custom Incident Runbook — done-for-you, built from your established stack — from $99

Related: the incident post-mortem template produces the actions, the small-team blameless review format runs the meeting, and this tracker is what keeps both honest in the weeks between. For the customer-facing side of the same lifecycle, see the outage email sequence.