Essential sections of a post-mortem

WHAT THIS TESTS Whether you can structure a document that informs quickly and drives durable fixes, with each section earning its place.

A GOOD ANSWER COVERS A summary at the top gives a busy reader the gist in a few sentences. The impact section quantifies who and what was affected, duration, and error-budget or revenue impact, so the severity is unambiguous. The timeline lays out events from detection through mitigation and resolution, anchoring all later discussion in facts. Root cause and contributing factors explain why it happened, going past the trigger to the conditions that allowed it. What went well and what went poorly capture response quality so good practices are reinforced and gaps named. Action items, prioritized, owned, and dated, are the payload that prevents recurrence. Detection and monitoring notes often appear too, since detection delay is a common failure.

COMMON WRONG ANSWERS A free-form story with no timeline, making causation hard to trace. No action items, so nothing changes. Action items with no owner or due date.

LIKELY FOLLOW-UPS How detailed should the timeline be? How do you keep action items from being forgotten? Should the impact be in business terms?

ONE CONCRETE EXAMPLE A post-mortem for a 90-minute API outage opens with a two-sentence summary, states 30 percent of requests failed affecting 12,000 users, gives a timeline from the 10:00 deploy to the 11:30 rollback, identifies a missing timeout as the contributing factor, notes the fast rollback as a win and the 40-minute detection lag as a gap, and lists three owned, dated action items: add the timeout, add a detection alert, and update the runbook.