Postmortems need a half-life

Not every lesson deserves a ticket

Incident rooms generate ideas under pressure. Add a dashboard. Rewrite the service. Improve the runbook. Change the ownership model. Recording every idea as corrective work creates volume without judgment.

Tie each action to a failure mode and expected risk reduction. If the team cannot state what recurrence it prevents, detects, or shortens, it is not corrective action yet.

Give actions an expiration condition

A corrective action should have an owner, due date, and closure evidence. It should also have a condition under which it can be dropped: the service retires, architecture changes, traffic moves, or another control makes the action redundant.

This half-life keeps the reliability backlog connected to the system that exists now instead of preserving the anxiety of every past incident.

• Failure mode addressed
• Expected risk reduction
• Named engineering owner
• Due date based on risk
• Evidence required for closure
• Condition that makes the action obsolete

Review risk, not ticket age

In the reliability review, rank open actions against current exposure. A recent low-impact incident may matter less than an older action attached to a repeated high-severity failure. Escalation should follow risk, not embarrassment.

Close actions only when the control exists and has been tested. A merged pull request is not evidence if the recovery path has never been exercised.

The postmortem is complete when the organization accepts, reduces, or removes the risk. Publishing the document is only the start.