Incident Postmortem Template: Turning One Incident Into Six Actionable Improvements
The purpose of a postmortem is not to assign blame; it is to make sure the same failure does not happen twice. Many teams hold a postmortem that turns into a blame session — or, just as common, a document that gets written, filed away in the wiki, and never read again. A good postmortem relies less on a fancy format and more on structured records plus improvements that actually get implemented. The template below follows Google SRE practice and can be used as-is.
Postmortem Structure: Six Fixed Sections
1. Incident Summary. Describe in three to five sentences what happened, when it happened, who was affected, and how long it lasted. The summary should let someone who was not involved understand the incident quickly.
2. Timeline. Record key events in chronological order, precise to the minute, using UTC to avoid timezone ambiguity. A timeline records facts without judgment — "12:03 alert received" rather than "12:03 we started panicking."
3. Root Cause Analysis. Ask "why" five times, layer by layer, until you reach something that can actually change in the system. Root causes are usually a combination of factors: "database connection pool exhausted" often hides "monitoring threshold set too late" + "connections had no timeout" + "no load test before release."
4. Impact Scope and Losses. Quantify the impact: how many users were affected, how many orders failed, an estimate of lost revenue, and SLA breach duration. The more concrete the numbers, the more convincing the improvement items.
5. Temporary Fix and Long-Term Fix. First write how you got it running again (rollback, restart, scaling), then how to keep it from recurring (code fix, architecture change, process improvement). Write both — many teams only write the long-term fix and forget the mitigation steps, so the next incident starts from scratch.
6. Owner and Deadline. Every improvement item must have an explicit owner and deadline, and the status of each item must be confirmed at the next postmortem.
The One Principle That Matters: No Individual Blame
Use a system-level voice: instead of "so-and-so made an operation error," ask "why did the system allow this misoperation to happen?" This is not just a cultural issue — it is an efficiency issue. Once blame enters the room, participants start hiding details, and the quality of the next postmortem's data drops. Google SRE calls this the blameless postmortem, and it is the foundation for continuously producing improvements.
A Filled-In Example (Simplified)
| Section | Example Content |
|---|---|
| Incident Summary | 2026-08-05 21:00–21:40, order API returned widespread 5xx, about 15% of users could not place orders |
| Timeline | 21:00 alert fired; 21:12 root cause identified as DB connection pool exhaustion; 21:25 scaled up and recovered; 21:40 metrics confirmed stable |
| Root Cause | Promo warm-up script released traffic without a load test; pool limit too small; no connection-leak monitoring |
| Impact | About 3,200 failed orders, estimated loss of about CNY 60,000, 40 minutes of SLA breach |
| Temporary Fix | Doubled the connection pool and restarted broken connections |
| Long-Term Fix | Add load testing to the release gate; add pool-usage alerts; fix the connection leak |
| Improvements | ① Load-test gate in release process (owner A, by 8/10) ② Pool monitoring alert (owner B, by 8/8) ③ Root-cause code review (owner C, by 8/12) |
How to Run the Meeting Efficiently
- Keep it to 45–60 minutes; do not write the document live in the meeting — prepare the timeline in advance
- The facilitator keeps the discussion on "what in the system needs to change" and away from "whose fault is it"
- The outcome must be a concrete improvement list; a postmortem without improvements is a wasted meeting
Store postmortems somewhere the whole team can reach (a wiki or the repo) and turn each improvement item into a trackable task. It also helps to track two numbers: MTTR (mean time to recovery) and the on-time completion rate of improvements — both say more about the long-term value of your postmortems than "no incidents this month."
Severity Levels and When a Postmortem Is Required
Not every incident deserves a full postmortem, but you should not reserve them for "big incidents" either. Assign a severity level:
| Level | Example | Postmortem Required |
|---|---|---|
| P0 | Core service down, financial impact | Mandatory, draft within 48h |
| P1 | Widespread feature failure, poor UX | Mandatory, draft within 72h |
| P2 | Localized impact, workaround exists | Recommended, sync in weekly review |
| P3 | Minor issue, temporary fix exists | Log only |
The point of grading is to spend limited postmortem effort where it matters, while giving P0/P1 a hard deadline. A postmortem is itself a rehearsal — run cheap P2 postmortems regularly so the team has rhythm before a real P0 hits.
Should postmortem output be part of performance reviews? Track whether improvement items are completed on schedule, rather than using "no incidents this month" as a metric. Fewer incidents follow from improvements that actually get implemented.
Reference: Google SRE on postmortem culture https://sre.google/sre-book/postmortem-culture/
Reference: Atlassian incident postmortem guide https://www.atlassian.com/incident-management/postmortems