Incident Post-Mortem Template (Blameless, With an Example)

A post-mortem is a short written review of an incident: what happened, what the impact was, why it happened, and what you will change. Blameless means it looks for causes in systems, processes and missing safeguards rather than in individuals. Write it within a few days, review it with everyone who was involved, and track the action items until they are done. The template below can be copied straight into your wiki or docs tool.

Why blameless matters

If people expect to be blamed, they share less, and the review ends at "someone made a mistake." That is almost never the useful answer. A person ran a command, merged a change or skipped a step because something made that action look reasonable: a missing check, an unclear runbook, an alert that fired too late. Fixing those things prevents the next incident; telling someone to be more careful does not.

Blameless does not mean nobody is accountable. It means accountability is expressed as owned action items, not as fault.

The template

Copy everything in the block below.

# Post-mortem: [short title]

Status: [Draft / In review / Final]
Date of incident: [YYYY-MM-DD]
Author(s): [names]
Reviewers: [names]

## Summary
[Two or three sentences: what broke, for how long, and who was affected.]

## Impact
- Duration: [start - end, time zone]
- Users affected: [who, how many or what share, if measured]
- Services affected: [list]
- Data: [lost / delayed / none]
- Customer contact: [support tickets, refunds, SLA credits]

## Detection
- How we found out: [monitor alert / customer report / internal user]
- Time from start to detection: [minutes]

## Timeline
[All times in one time zone.]
- [HH:MM] [event]
- [HH:MM] [event]

## Root cause and contributing factors
[What caused the failure, and what made it possible, worse or slower to fix.]

## Resolution
[What fixed it, and whether that fix is permanent or temporary.]

## What went well
- [item]

## What went poorly
- [item]

## Where we got lucky
- [item]

## Action items
| Action | Type | Owner | Due | Status |
|---|---|---|---|---|
| [action] | [prevent / detect / mitigate / process] | [name] | [date] | [open] |

## Lessons learned
[Anything the team understands now that it did not before.]

Each section explained

Summary

Write it last. Someone who reads only this paragraph should know what broke, for how long and whether customers were affected. Avoid jargon, because managers, support staff and sometimes customers read it.

Impact

Use measured numbers where you have them: failed requests from logs, affected accounts from the database, tickets from your helpdesk. If you do not have a number, say "not measured" and consider making that an action item. Do not estimate to make the incident sound smaller or larger.

Detection

This section is the one teams skip and the one that often produces the most valuable fix. Record how you learned about the incident and how long that took. If a customer told you before any alert fired, that gap is a finding in itself. Time to detect is one part of time to recover, and it is often the cheapest part to shorten: an external uptime check on the affected URL, a keyword check for pages that fail with a 200 status, or a heartbeat for a scheduled job.

Timeline

List events with timestamps in one time zone: when the triggering change happened, when symptoms started, when the alert fired, when someone acknowledged it, key decisions, the fix, and full recovery. Pull times from logs, chat history, deploy records and monitoring rather than memory. Include decisions that turned out to be wrong, without judgment: "14:05 Restarted the web server, assuming a memory leak. Errors continued."

Root cause and contributing factors

Ask "why" repeatedly until you reach something you can change. Complex incidents rarely have a single cause, so list contributing factors as well: a missing test, an alert threshold set too high, a runbook that described an old setup. Phrase every factor in terms of the system. "The deploy pipeline did not validate configuration" is actionable. "Sam deployed a bad config" is not.

Resolution

Say what restored service and whether it is a lasting fix or a workaround. If it was a rollback, the underlying problem still needs an action item.

What went well, what went poorly, where we got lucky

"What went well" reinforces habits worth keeping. "Where we got lucky" is the most honest section: the incident happened at a quiet hour, the one person who knew the system was online. Luck is not a plan, so lucky breaks usually turn into action items.

Action items

Every item needs one owner and a due date. Tag each by type so you can see the balance:

• Prevent: stop this cause from recurring (validation, tests, guardrails).
• Detect: find out sooner (new monitors, better alert thresholds).
• Mitigate: reduce impact next time (feature flags, faster rollback, graceful degradation).
• Process: runbooks, on-call, communication.

Keep the list short enough to finish. Five items that get done are worth more than fifteen that sit open. Review open items at a regular team meeting until they are closed.

Example (fictional)

The following is a short, invented example for illustration only. Example Co. is not a real company and the numbers are made up.

Post-mortem: Password reset emails not delivered

Summary. For about 6 hours on a Tuesday, Example Co. customers who requested a password reset did not receive the email. Logins with existing passwords were not affected.

Impact. 09:10 to 15:20 UTC. 212 reset requests produced no email, according to application logs. 31 support tickets. No data lost.

Detection. A support agent noticed the pattern in tickets at 14:30 UTC, more than 5 hours after the problem began. No monitor covered email delivery.

Timeline (UTC).

• 09:05 Scheduled rotation of the email provider API key runs.
• 09:10 First reset email fails with an authentication error. The error is logged but does not alert.
• 14:30 Support escalates to engineering.
• 14:50 Engineer finds authentication errors in the email worker log.
• 15:10 Worker configuration updated with the new key, worker restarted.
• 15:20 Test reset email delivered. Queued emails are not retried, so affected users are contacted manually.

Root cause and contributing factors. The key rotation script updated the key in the secrets store, but the email worker reads the key only at startup and was not restarted. Contributing factors: the rotation runbook did not mention the worker; email send failures were logged without alerting; failed sends were dropped instead of retried.

What went well. Support spotted the pattern and escalated with useful examples. The fix took 20 minutes once found.

Where we got lucky. The failure did not affect signup confirmation emails, which use a different sender.

Action items.

Note how the example never names an individual, records the 5-hour detection gap honestly, and turns the lucky break into an awareness rather than an assumption.

Running the review meeting

Share the draft a day before. In the meeting, walk the timeline first, because people often correct details there, then discuss causes and agree on action items. Thirty to sixty minutes is enough for most incidents. The facilitator's main job is to steer questions from "who" to "what" and "why."

For customer-facing incidents, turn the final document into a short public summary. The incident communication templates include a follow-up format, and a status page is the natural place to publish it.

Track whether reviews pay off

Over a few months, look across post-mortems for patterns: the same service, the same kind of change, the same detection gap. Two useful numbers to track are time to detect and time to recover. PingRobot records when each monitor went down and came back up, which gives you the detection and recovery timestamps for the timeline without digging through chat history.

Start monitoring free — 10 monitors, no credit card.