Checklist
Give every postmortem action a verifiable finish
'Improve reliability' is a wish wearing an action-item field.
When it fits
- A postmortem produces follow-ups such as 'improve monitoring' or 'be more careful.'
When to avoid it
- A completed action is not proof the same class of incident cannot recur; risk should be reassessed separately.
Checklist
- The action names a concrete change or artifact.
- An owner is explicit.
- A reviewer can observe a pass condition.
- The action addresses prevention, mitigation or detection rather than only restating the incident.
- Completion does not depend on someone claiming they will 'be more careful.'
Why it matters
Rewrite each follow-up so a reviewer can determine whether it is complete without interpreting intention. Name the artifact or system change, the condition it should create, an owner and a completion check. Prefer changes to the system or process over telling people to remember harder.
An example
Replace 'monitor queue growth better' with 'alert when queue age exceeds the agreed threshold for the defined service window.'
Check your result
A person who did not attend the incident can say whether the action is done.
Keep this limit in mind
- A completed action is not proof the same class of incident cannot recur; risk should be reassessed separately.
Connected ideas
Use beforeMine postmortems for repeated failure patterns
Evidence and sources
Supports
Google SRE postmortem guidance treats a verifiable end state as a quality criterion for follow-up action items.
A measurable completion state does not by itself prove that recurrence risk has been eliminated.
Postmortem Culture: Learning from Failure · Measurability; action items