Primary goal and sections of a post-mortem

WHAT THIS TESTS Whether you grasp that post-mortems exist to make the system more reliable over time, and whether you can structure a document that actually drives change.

A GOOD ANSWER COVERS The primary goal is organizational learning and recurrence prevention: convert a painful event into systemic improvements and shared understanding. A strong document opens with a concise summary so a busy reader gets the gist, then states impact (users, duration, revenue or SLO burn) and how it was detected. A detailed timeline anchors discussion in facts. The root cause and contributing factors section digs past the trigger to underlying conditions. A what-went-well and what-went-poorly section captures response quality. Finally, specific, owned, prioritized action items with due dates make the learning actionable.

COMMON WRONG ANSWERS Saying the goal is to find who caused it. Listing only a narrative with no action items, or vague items like improve monitoring with no owner.

LIKELY FOLLOW-UPS How do you ensure action items get done? Who should write and review the post-mortem? When is one required?

ONE CONCRETE EXAMPLE After a two-hour outage, the doc summarizes that a config change exhausted connections, lists 40 minutes of detection delay and the affected user count, gives a minute-by-minute timeline, identifies the missing connection-limit alert as a contributing factor, praises the fast rollback, and lists three owned items: add the alert, add a config validation gate, and a runbook update, each with an owner and date tracked in the backlog.