A blameless incident postmortem template that gets used
A postmortem template gives every incident review the same structure: what happened, the impact, a timeline, why it happened, what went well, and owned action items with due dates. Copy the template below, then read on for how to run a blameless postmortem and, the part most teams skip, how to follow through.
I’ve built payment and loyalty platforms with millions of users, where an incident costs real money. The lesson: the document matters less than the habits around it.
The postmortem template
Keep each section short. A postmortem that takes a day to write won’t get written for the medium-sized incidents, and those are where the cheapest lessons are.
- Title and ID: a short, factual name. “Checkout errors after payment provider timeout change,” not “The Tuesday disaster.”
- Status and metadata: severity, date, duration, incident lead, postmortem author, review date, status (draft, reviewed, actions complete).
- Summary (3–5 sentences): what broke, who was affected, for how long, how it was fixed. Readable by someone outside engineering.
- Impact: customers or requests affected, revenue or data impact, SLO budget consumed, support tickets raised. Numbers where you have them, “unknown” where you don’t.
- Timeline (UTC): timestamped entries from first trigger to full resolution. Include when the problem started, when it was detected, when someone responded, key decisions, mitigation, and resolution.
- Detection: how we found out. Alert, customer report, or someone happened to notice. How long between start and detection.
- Root cause and contributing factors: the technical chain of events, and the conditions that let it happen. Usually several factors, not one cause.
- What went well: things that limited the damage. These are worth keeping deliberately.
- What went poorly: gaps in detection, response, tooling or documentation.
- Where we got lucky: things that could easily have made it worse. Often the most useful section.
- Action items: each with an owner, a due date, a ticket link and a type (prevent, detect, mitigate, process).
- Lessons and links: dashboards, logs, related incidents, the chat channel transcript.
What makes a postmortem blameless
A blameless postmortem assumes everyone involved acted reasonably given what they knew at the time. It asks “why did this make sense to the person doing it?” rather than “who messed up?”
This isn’t softness. It’s practical. If people expect blame, they hide details, and the details are where the fix is. The engineer who ran the wrong migration knows exactly which part of the runbook was ambiguous, but only tells you if it’s safe to.
In the document, that means describing actions, not judging people. “The deploy was triggered with the staging config” rather than “Alex deployed the wrong config.” Names belong in the timeline as roles where possible, and nowhere in the root cause.
When to write a postmortem
Set the triggers in advance so nobody has to decide in the moment whether an incident “counts”:
- Any customer-visible outage or degradation beyond a threshold you define (for example, beyond a set number of minutes).
- Any data loss, data exposure or incorrect charges, regardless of duration.
- Any incident that needed a rollback or emergency hotfix in production.
- Any near miss that would have qualified had you been less lucky.
- Any time someone asks for one. Make that a right, not a request.
How to run the postmortem review
- Draft first, meet second. The incident lead or a designated author drafts the document within two working days, while memory is fresh.
- Invite the responders and the owners of the systems involved. Keep it under ten people. Make it open to anyone who wants to listen.
- Walk the timeline before discussing causes. Most disagreements come from people holding different versions of what happened.
- Ask “how” and “what” more than “why”. “What did the dashboard show at that point?” gets better answers than “why didn’t you notice?”
- Look for several contributing factors. “Five whys” tends to produce one tidy root cause. Real incidents usually have a few: a change, a missing alert, a confusing runbook and a busy afternoon.
- Agree action items in the room, each with a named owner and a date. Fewer, better actions beat a long list nobody does.
- Keep it to an hour. If you need longer, the incident was big enough to warrant a second session.
Following through on action items
This is where most incident management processes quietly fail. The document gets written, the meeting is good, and the action items sit in the backlog until the same incident happens again.
What works:
- Put actions in the normal backlog with a postmortem label, not in the document alone.
- Prioritize by type. Detection and mitigation fixes are often cheap and high value; do those first. Large prevention projects go on the technology roadmap with an explicit owner.
- Review open actions weekly in the engineering sync until they’re done. A short list read aloud is surprisingly effective.
- Mark the postmortem complete only when all actions are closed or consciously dropped with a reason.
- Look across postmortems quarterly. Recurring contributing factors (the same flaky dependency, the same missing alert) are the real priorities.
Postmortems and your delivery metrics
Every postmortem should record when the problem started, when it was detected and when service was restored. Those timestamps give you recovery time and help you calculate change failure rate, two of the DORA metrics. Over a year, they show whether your incident response is actually improving.
Postmortems also feed on-call health. If the same alert pages people every week and the postmortems keep saying “noisy alert, ignored,” fix the alert. I’ve written about that in setting up a sustainable on-call rotation.
Getting started in a small team
If you’ve never written one, start with your last notable incident, even if it was weeks ago. Fill the template as far as you can, hold a 30-minute review, and pick two actions. That first one sets the tone more than any policy document.
If incidents are frequent enough that postmortems feel like a second job, the problem is upstream in the deploy pipeline and test coverage. That’s the work I do in DevOps consulting: fewer incidents first, better postmortems second.
Questions
What should an incident postmortem include?
A short summary, the customer and business impact, a timestamped timeline, how the problem was detected, the root cause and contributing factors, what went well and poorly, where you got lucky, and action items with owners and due dates. Keep it short enough that people will write one for medium incidents too.
What is a blameless postmortem?
A review that assumes everyone acted reasonably given the information and tools they had, and looks for the system conditions that made the failure possible. It focuses on what happened and how, not who to blame, because people only share the useful details when it’s safe to.
How soon after an incident should you write the postmortem?
Draft it within two working days and hold the review within a week. Memory fades fast, and chat logs lose context. Capture the timeline during the incident itself if you can, by keeping a running log in the incident channel.
Who should own postmortem action items?
A single named person per action, usually from the team that owns the affected system, with a due date and a ticket in the normal backlog. Shared ownership means nobody owns it. Review open actions weekly until they are closed or explicitly dropped.
Same incidents, different week?
I’ll join your team for a two-week sprint, read your last few postmortems, and ship the fixes that stop the repeat offenders.
GMT+2 · Full EU overlap · US East mornings