A postmortem is a written record of an incident that captures what happened, why it happened, and what will change to prevent it from happening again.
A postmortem documents the incident timeline, detection path, mitigation steps, root cause, and action items. Blameless postmortems separate human error from systemic gaps so teams can fix the conditions that made the error possible.
That separation is what turns postmortems from punishment documents into engineering improvements. If engineers fear blame, they hide details and the next incident repeats. If the document focuses on system design, alert coverage, and process gaps, the organization learns. The best postmortems include timeline reconstruction, blast radius assessment, and tracked follow-up tasks with owners.
Think of it like this. Think of an aircraft crash investigation. The goal is not to punish the pilot, but to change the procedures, instruments, and training so the same failure cannot happen again.
After an incident resolves, the involved engineers reconstruct the timeline from logs, metrics, and chat history. They identify contributing factors, not just a single root cause. They write action items with owners and due dates. Review meetings discuss findings without personal blame.
"Postmortems should find someone to blame." That creates hidden failures and repeated outages. "One root cause explains everything." Complex systems usually have multiple contributing factors. "Action items are enough without follow-up." Untracked action items become decoration.
Creates durable organizational learning, but requires cultural safety and follow-through discipline. Quick lightweight postmortems maintain momentum; heavy processes delay learning and increase toil.