The final output of the post-incident analysis process is the Post-Mortem Report — a written document that captures what happened, why it happened, and what will be done to prevent recurrence. This document should be widely shared within the organization so that teams who were not involved can also learn from the incident.
Standard Post-Mortem Structure
1. Executive Summary
Two to four sentences covering: what broke, when, for how long, what the customer impact was, and the primary contributing factors. Written for a non-technical audience (e.g., a VP or a customer success manager).
2. Timeline
A chronological, timestamped account of the incident from the first sign of trouble to full resolution. Include when alerts fired, when engineers were paged, when key diagnostic steps were taken, when mitigations were applied, and when the incident was declared resolved. This is the most factual section — no interpretation, just what happened and when.
3. Contributing Factors
A detailed explanation of the systemic failures identified using the 5 Whys, Fishbone, or other analysis techniques. This section explains why the incident happened, not just what happened.
4. Action Items (The Most Important Section)
A list of specific, concrete tasks to prevent recurrence or reduce impact. Each action item must have:
- A clear description of the work
- An assigned owner (a specific person, not a team)
- A due date
The quality of action items is what separates a useful post-mortem from a document that gets filed and forgotten.
| Quality | Example |
|---|---|
| ❌ Bad | "Be more careful next time." |
| ❌ Bad | "Improve monitoring." |
| ✅ Good | "Jane Doe to add a pre-deployment check in the CI pipeline that runs EXPLAIN ANALYZE on all new queries and fails the build if a full table scan is detected on tables with >100k rows. Due: 2024-02-15." |
| ✅ Good | "Ravi Patel to implement a Datadog monitor that pages the on-call engineer 30 days before any API key stored in Vault expires. Due: 2024-02-01." |
5. What Went Well
Often omitted but genuinely valuable. Document the things that worked: the alert that fired quickly, the runbook that was accurate, the engineer who made a great call under pressure. This reinforces good practices and gives the team something to feel good about after a stressful event.
The Post-Mortem Meeting
The written report is produced after a structured meeting where the team walks through the timeline together, applies analysis techniques, and agrees on contributing factors and action items. The meeting facilitator should be someone neutral — ideally not the incident commander — and should actively enforce the blameless norm if the discussion starts to drift toward individual blame.
Interviewers sometimes ask: "How do you ensure post-mortem action items actually get done?" A weak answer is "we track them in Jira." A strong answer describes a system: action items are filed as tickets in the team's sprint backlog (not a separate "post-mortem tracker" that nobody checks), they have owners and due dates, and there is a recurring review — perhaps monthly — where the team checks the status of all open post-mortem action items. The key insight is that action items without organizational follow-through are just good intentions.