Software Incident Postmortem Checklist

A postmortem should help the business reduce repeat impact and improve detection, response, recovery, or communication. It should be a factual learning record, not a search for a person to blame or a vague promise to “be more careful.”

Record the impact

Describe affected users, workflows, data, duration, geography or departments, customer communication, revenue or service consequence, and what remained available. Separate confirmed impact from unknowns.

Build a timeline

Record change, first symptom, detection, alert, report, investigation, mitigation, recovery, communication, reconciliation, and closure with time zone and source evidence. Avoid rewriting the timeline after the outcome is known.

Explain cause and contributors

Describe technical cause, process, data, dependency, configuration, monitoring, access, capacity, or communication factors that allowed the impact. Focus on conditions the system can improve rather than one person's mistake.

The incident communication checklist and restore test checklist cover response and recovery.

Evaluate detection and response

Ask what detected the issue, how long it took, whether the signal was actionable, who owned the response, whether the workaround worked, and what evidence was missing. Include customer or support observations.

List corrective actions

Write action, owner, due date, priority, evidence, dependency, and success condition. Include code, configuration, test, monitoring, documentation, training, vendor, data, and communication actions as relevant.

Share safely

Remove credentials, private records, security-sensitive exploit details, and unnecessary personal information. Share the learning with the people who can act and keep a restricted technical record when appropriate.

Verify improvements

Revisit actions after the release, drill, or process change. Check that alerts fire, recovery works, staff understand the fallback, and the business can demonstrate a lower likelihood or impact of repeat failure.