The template
Copy it in the format your team writes in. Text in square brackets is a prompt to replace. Times are in UTC so the document reads the same for everyone.
Paste into GitHub, GitLab, Notion, Linear or any Markdown editor.
# Postmortem: [incident name]
## Summary
| Field | Value |
| --- | --- |
| Incident | [one-line name, e.g. Checkout API returned 503s] |
| Affected service | [service or component] |
| Started | [YYYY-MM-DD HH:MM UTC] |
| Resolved | [YYYY-MM-DD HH:MM UTC] |
| Duration | [from first impact to full recovery] |
| Regions affected | [all, or which] |
| Detected by | [monitor alert, customer report, engineer] |
| Acknowledged by | [on-call engineer] |
| Severity | [SEV1, SEV2 or SEV3] |
| Author | [name] |
| Status | Draft |
[Two or three sentences a reader outside the team can follow: what broke, who noticed, how long it lasted and how it was fixed.]
## Impact
- [Who was affected: customers, regions, plans]
- [What they could not do]
- [How many requests, users or orders, if known]
- [SLA or error budget consumed]
## Timeline
All times in UTC. Include detection, each decision, and recovery.
| Time (UTC) | Source | Event |
| --- | --- | --- |
| [HH:MM] | Monitor | First check failed in [region] |
| [HH:MM] | Team | [Name] acknowledged the alert |
| [HH:MM] | Status | Investigating update posted |
| [HH:MM] | Team | [Cause identified, fix started] |
| [HH:MM] | Monitor | Checks passing again in every region |
| [HH:MM] | Status | Resolved update posted |
## Root cause and contributing factors
[What happened in the system, not who did it. Ask why until you reach something the team can change.]
- [Trigger]
- [Root cause]
- [Contributing factors]
## Detection and response
- [How was it detected, and how long after it started?]
- [How long until someone acknowledged and started work?]
- [When were customers told, and through which channel?]
## What went well
- [item]
## What went wrong
- [item]
## Where we got lucky
- [item]
## Action items
| Action | Type | Owner | Due | Ticket |
| --- | --- | --- | --- | --- |
| [action] | Prevent | [owner] | [date] | [link] |
| [action] | Detect | [owner] | [date] | [link] |
| [action] | Mitigate | [owner] | [date] | [link] |
A filled example
A fictional 47-minute checkout outage, with the record-keeping parts done. The prompts that are left are the ones a team fills in together in the review.
Paste into GitHub, GitLab, Notion, Linear or any Markdown editor.
# Postmortem: Checkout API returned 503s
## Summary
| Field | Value |
| --- | --- |
| Incident | Checkout API returned 503s |
| Affected service | Checkout API |
| Started | 2026-10-14 13:02 UTC |
| Resolved | 2026-10-14 13:49 UTC |
| Duration | 47 min |
| Regions affected | US East, EU West |
| Detected by | Monitor |
| Acknowledged by | Priya |
| Severity | [SEV1, SEV2 or SEV3] |
| Author | [name] |
| Status | Draft |
[Two or three sentences a reader outside the team can follow: what broke, who noticed, how long it lasted and how it was fixed.]
## Impact
- [Who was affected: customers, regions, plans]
- [What they could not do]
- [How many requests, users or orders, if known]
- [SLA or error budget consumed]
## Timeline
From the incident record, in UTC. Add the decisions and actions that are not in it.
| Time (UTC) | Source | Event |
| --- | --- | --- |
| 2026-10-14 12:58 UTC | Team | Deploy 418 started: connection pool size moved to config |
| 2026-10-14 13:02 UTC | Monitor | Checkout API down: 503 from US East |
| 2026-10-14 13:04 UTC | Monitor | Checkout API down: 503 from EU West |
| 2026-10-14 13:06 UTC | Team | Priya acknowledged |
| 2026-10-14 13:09 UTC | Status | Investigating: Some customers cannot complete checkout |
| 2026-10-14 13:31 UTC | Team | Pool size found unset in production config, defaulting to 1 |
| 2026-10-14 13:38 UTC | Team | Deploy 418 rolled back |
| 2026-10-14 13:49 UTC | Monitor | Checkout API recovered in every region |
| 2026-10-14 13:52 UTC | Status | Resolved |
## Root cause and contributing factors
[What happened in the system, not who did it. Ask why until you reach something the team can change.]
- [Trigger]
- [Root cause]
- [Contributing factors]
## Detection and response
- [How was it detected, and how long after it started?]
- [How long until someone acknowledged and started work?]
- [When were customers told, and through which channel?]
## What went well
- [item]
## What went wrong
- [item]
## Where we got lucky
- [item]
## Action items
| Action | Type | Owner | Due | Ticket |
| --- | --- | --- | --- | --- |
| [action] | Prevent | [owner] | [date] | [link] |
| [action] | Detect | [owner] | [date] | [link] |
| [action] | Mitigate | [owner] | [date] | [link] |
What blameless means
A blameless postmortem asks what in the system let a reasonable person’s action cause an outage, not who made the mistake. In the example, “someone shipped a bad config” is true and useless; “a missing setting fell back to a pool of one and nothing checked it” leads to a fix. People describe what they actually did and saw only when it cannot be held against them, and without that the timeline is guesswork.
What each section is for
- Summary: the facts at a glance, and a paragraph a reader outside the team can follow.
- Impact: who was affected and how, in numbers where you have them. This is what decides the severity, not how stressful the incident felt.
- Timeline: detection, every decision, and recovery, in UTC. The gaps in it, such as twenty minutes between the alert and the first action, are often the most useful finding.
- Root cause and contributing factors: keep asking why until you reach something the team can change. There is usually more than one factor.
- Detection and response: how long it took to notice, to start work and to tell customers. Each is its own thing to improve.
- What went well, what went wrong, where we got lucky: the last one finds the next incident before it happens.
- Action items: each with an owner, a date and a ticket, marked as prevent, detect or mitigate. An action item with no owner does not get done.
Running the review
Write the draft within two working days, while memory is fresh, then meet for under an hour with the people who responded. Walk the timeline first and agree on what happened before discussing causes. Publish the result where the whole engineering team can read it, and review open action items until they are done. For incidents customers saw, a short public version on your status page closes the loop with them: see incident communication templates.
Prefilled from your incidents
The slowest part of a postmortem is rebuilding the timeline. On paid plans, every incident in RealUptime has a “Draft a postmortem” button that fills this template from the incident record: start and end, duration, regions, who acknowledged, every status update, and the check failures, error spikes and third-party outages that fell in the same window. You keep the judgment calls; the record-keeping is done.
Next