The incident post-mortem template that fits on one page
Most post-mortem templates have 15+ sections: executive summary, timeline, impact assessment, five-whys, contributing factors, lessons learned, action items, appendices. On a small team, that's exactly the kind of document that gets started the day after an incident and never finished. The post-mortem that actually gets written is the one that fits on one page.
What are the 5 questions every post-mortem needs to answer?
What broke and what was the user-visible impact, how long between impact starting and the first signal reaching a human, what specifically made diagnosis take as long as it did, was the fix a permanent solution or a stop-gap, and what is the single owned change that prevents this exact failure — with a name and a date attached. Every other section is optional context.
- 1. What broke, and what was the user-visible impact? — with exact start and end timestamps, not "around 2pm"
- 2. What was the first signal, and how long after impact actually started? — this is your real detection gap (MTTD), separate from MTTR
- 3. What made diagnosis take as long as it did? — the specific mechanism, not "the database was slow"
- 4. Was the fix permanent or a mitigation? — restarting a task and fixing the memory leak that caused the OOM are different outcomes
- 5. What is the one change that prevents this exact failure from recurring, who owns it, and by when? — one owned item beats five vague ones
The copy-paste template
# Incident post-mortem: [one-line description]
**Date of incident:** YYYY-MM-DD
**Severity:** SEV-1 / SEV-2 / SEV-3
**Author:** [name]
**Status:** Draft / Reviewed / Action items tracked
## 1. What broke, and what was the impact?
- Start time (UTC):
- End time (UTC):
- Duration:
- Who was affected, and how (error rate, latency, full outage, data issue):
## 2. What was the first signal, and how long after impact started?
- First signal (alarm, customer report, manual discovery):
- Time from impact start to first signal:
- Time from first signal to first human response:
## 3. What made diagnosis take as long as it did?
- Root cause (the specific mechanism, not the symptom):
- What made this hard to find (missing logs, wrong alarm, unclear ownership):
## 4. What was the fix?
- Immediate mitigation (stopped the bleeding):
- Permanent fix (if different from above, and its status):
## 5. What prevents this from happening again?
- Action item:
- Owner:
- Due date:
(Repeat only if there is a genuinely separate second action item — most incidents need one, not five.)Filled-in example: an RDS connection exhaustion outage
A hypothetical but representative incident — the pattern below matches how "too many connections" outages actually unfold on a small team running a connection-pooled API against RDS.
# Incident post-mortem: API returning 500s due to RDS connection exhaustion
**Date of incident:** 2026-06-14
**Severity:** SEV-1
**Author:** on-call engineer
**Status:** Action items tracked
## 1. What broke, and what was the impact?
- Start time (UTC): 14:02
- End time (UTC): 14:31
- Duration: 29 minutes
- Impact: ~40% of API requests returned 500 (connection pool exhausted). Checkout flow affected for logged-in users.
## 2. What was the first signal, and how long after impact started?
- First signal: RDS DatabaseConnections alarm (>90% of max_connections) at 14:09
- Time from impact start to first signal: 7 minutes
- Time from first signal to first human response: 3 minutes (on-call acknowledged via WhatsApp)
## 3. What made diagnosis take as long as it did?
- Root cause: a deploy at 13:58 introduced a code path that opened a new DB connection per request instead of reusing the pool, in one rarely-hit error-handling branch.
- What made this hard to find: the connection leak only triggered on a specific error path that wasn't covered by the smoke test after deploy — CloudWatch Logs Insights query on RDS logs plus correlating with the 13:58 deploy timestamp found it in 12 minutes.
## 4. What was the fix?
- Immediate mitigation: rolled back the 13:58 deploy at 14:24, connections recovered by 14:31.
- Permanent fix: patched the error-handling branch to use the existing pooled connection; shipped and verified same day.
## 5. What prevents this from happening again?
- Action item: add a connection-pool assertion to the post-deploy smoke test that fails the deploy if active connections exceed a fixed threshold within 2 minutes of rollout.
- Owner: backend lead
- Due date: 2026-06-21Notice what's absent: no five-whys diagram, no stakeholder sign-off matrix, no severity rubric essay. Those have their place in larger organizations with dedicated incident commanders. On a small team, the document that gets written, read, and acted on is the one that takes 15 minutes to fill in in the day after the incident — not the one that requires a meeting to schedule.
What to do with the action item after the post-mortem
A post-mortem with an unowned action item is a post-mortem that didn't happen. Put the action item directly into your issue tracker with the owner and due date from section 5 — not as a follow-up task to "file a ticket later." If the fix genuinely can't ship within two weeks, that's a signal the team is choosing to accept the recurrence risk — make that an explicit decision, not a default.
Related reading
Frequently asked questions
Frequently asked questions
What is a good incident post-mortem template?
A good template is short enough to actually get filled in. At minimum it should answer 5 questions: what broke and what was the user-visible impact, how long between impact and detection, what made diagnosis take as long as it did, whether the fix was permanent or a mitigation, and what single owned change prevents recurrence. Templates with 10+ sections often produce documents that get started and abandoned.
Should post-mortems be blameless?
Yes. A blameless post-mortem focuses on the systems and processes that allowed an incident to happen, not on the individual who deployed the change or wrote the bug. Naming a person as the cause discourages the honest detail-sharing needed to actually find the root cause — engineers route around blame rather than surfacing it.
How long should writing a post-mortem take?
For a single-page template like this one, 15-30 minutes for the author to draft, plus a short review if others were involved in the incident. If a post-mortem is taking hours to write, the template is too long for the team's actual process maturity — cut it down rather than skip writing it entirely.
Who should attend a post-mortem review?
Anyone who was part of the incident response, plus anyone who owns a system involved in the root cause or the fix. For small teams, this is often just the on-call engineer and one reviewer. Post-mortems don't require a formal meeting — an async written review with comments is often faster and just as effective.
What's the difference between a root cause and a contributing factor?
The root cause is the specific mechanism that caused the failure — e.g., "a code path opened a new DB connection per request instead of reusing the pool." A contributing factor is something that made the incident worse or harder to catch — e.g., "the smoke test didn't cover that error path." Good post-mortems name the root cause precisely and list contributing factors separately, rather than blending them into one vague explanation.
Related reading
Still debugging incidents manually?
Nuberio does this automatically — root cause in under 60 seconds, delivered to WhatsApp or Slack.