Tracking postmortem action items to closure: tracking bugs, single owners and ageing review

Goal

Make sure the changes a postmortem promises actually happen, and make it visible when they do not, so the same incident cannot recur with a document already predicting it.

Prerequisites

A postmortem practice that produces action items, an issue tracker everyone uses, and a recurring operations or reliability meeting.

Steps

1. At the postmortem review, rewrite each item until it names a system change with a completion criterion. The workbook's example of a bad postmortem uses phrases like "improve" and "make better" and lists items without owners; each of those is sent back.
2. Give each item exactly one owner, a priority, a type (the workbook's example table uses investigate, prevent, mitigate, repair and detect) and a tracking bug. The SRE book states that once those involved are satisfied with the document and its action items, the postmortem is added to a repository of past incidents; link the bug from the document and the document from the bug before that happens.
3. Mark at least one item as the preventative fix for the trigger; if none is feasible, the document says so and why. The workbook notes that changing human behaviour is less reliable than changing automated systems, so "be more careful" items do not count.
4. Set due dates by priority. The workbook quotes the rule that all postmortems following a user-affecting outage must have at least one P0 or P1 bug associated with them; adopt a local equivalent.
5. Review open items every two to four weeks in the standing meeting, sorted by age. For each item past its date choose one of: do it now, re-scope it, or close it as "will not do" with the reason written in both the bug and the postmortem. Leaving it on the list unchanged is not an option.
6. When an item closes, record in the postmortem what changed and how it was verified: the new alert fired in a test, the runbook was used in a drill, the limit is enforced by configuration.
7. Quarterly, count items opened, closed and dropped and read the dropped ones together; a pattern of dropped preventative items is itself a finding.

Expected result

A postmortem archive where every item is done, explicitly declined, or visibly overdue, and a team that can say what an incident changed.

Limits and test basis

Large items (rewrites, migrations) belong in the roadmap with the postmortem linking to them; tracking them as action items produces permanent overdue lines. The procedure follows the cited chapters; no completion rates are claimed.