How to Write a Blameless Post-Mortem (Free Template)

A post-mortem's value comes entirely from honesty. If engineers write around the truth to avoid blame, the document becomes useless - the same failure mode repeats six months later under a different name. Blameless doesn't mean consequence-free; it means the process assumes people made reasonable decisions with the information they had, and focuses on fixing systems, not people.

What "blameless" actually means

Blameless post-mortems separate two questions that are often conflated:

• "What happened, and why did our systems allow it?" (systems question)
• "Who made the mistake?" (blame question)

A blameless process asks only the first. It assumes the engineer who ran the migration, merged the PR, or missed the alert was acting reasonably given the context, tooling, and information available at the time. The fix is almost always a process, tooling, or documentation gap - not a person needing to "be more careful."

When to write one

Not every incident needs a full post-mortem. A reasonable policy:

Structure of a good post-mortem

Every effective post-mortem answers the same core questions in order:

1. What happened - a factual, timestamped summary.
2. Impact - who and what was affected, and for how long.
3. Timeline - the detailed sequence of detection, diagnosis, and resolution.
4. Root cause and contributing factors - the technical and process reasons, plural.
5. What went well - genuinely useful, not filler.
6. Action items - specific, owned, and time-bound.

Root cause vs. contributing factors

Avoid stopping at a single root cause. Most real incidents have three or four contributing factors that compounded:

Incident: Checkout API down for 47 minutes

Root cause: Database migration locked the primary table during
peak traffic.

Contributing factors:
- Migration was not tested against production-sized data volume
- No automated check flagged long-running locks before rollout
- On-call engineer had no runbook for database lock diagnosis
- Alert threshold was too high, delaying detection by 12 minutes

Listing contributing factors this way naturally produces multiple independent action items instead of one fix that only addresses the surface cause.

Writing effective action items

Vague action items ("be more careful with migrations") don't survive contact with the next sprint planning. Every action item needs an owner, a deadline, and a concrete deliverable.

The free post-mortem template

Copy this directly into your incident doc:

# Post-Mortem: [Incident Title]

**Date of incident:** YYYY-MM-DD
**Author(s):**
**Status:** Draft / Reviewed / Final
**Severity:** SEV1 / SEV2 / SEV3

## Summary
One paragraph: what happened, what was the impact, how long did it last.

## Impact
- Customer-facing impact:
- Internal impact:
- Duration:
- Number of affected users/requests (if known):

## Timeline (UTC)
| Time | Event |
|---|---|
| 14:02 | Alert fired |
| 14:04 | IC assigned |
| 14:15 | Root cause identified |
| 14:32 | Resolved |

## Root Cause
Describe the primary technical cause.

## Contributing Factors
- Factor 1
- Factor 2
- Factor 3

## What Went Well
- Detection was fast because of confirmed uptime checks
- Rollback procedure worked as documented

## What Could Have Gone Better
- Alert threshold delayed detection by 12 minutes
- No runbook existed for this failure mode

## Action Items
| Action | Owner | Due Date | Status |
|---|---|---|---|
| Add staging migration test with production-size data | @maria | 2024-06-20 | Open |
| Lower error-rate alert threshold to 3% | @devon | 2024-06-15 | Open |
| Write database lock runbook | @sam | 2024-06-25 | Open |

## Lessons Learned
Short summary of the generalizable lesson for the team.

Common mistakes to avoid

• Writing it too late. Memory fades fast; draft within 48 hours of a SEV1.
• Naming individuals as the cause. Say "the deploy script lacked a validation step," not "Jake forgot to validate."
• Skipping the "what went well" section. It reinforces good practices worth repeating, like fast detection from uptime monitoring or API monitoring catching the issue before customers reported it.
• Action items with no owner or date. These silently die in a backlog.
• No follow-up. Review open action items in your next team meeting, or they never close.

Running the review meeting

Keep it to 30 minutes for most incidents:

• 5 min: read the draft silently together (don't present it out loud - reading is faster)
• 15 min: discuss root cause, contributing factors, and gaps in the draft
• 10 min: confirm action items, owners, and dates

FAQ

Who should write the post-mortem?

Typically the incident commander drafts it with input from responders, since they have the clearest timeline. It should be reviewed by the whole team, not just approved by one person.

How long should a post-mortem be?

Long enough to cover the template sections honestly - usually one to two pages. Length isn't the goal; specific, owned action items are.

What if the root cause was a vendor outage outside our control?

Still write it. Focus on your response: detection speed, communication, and whether you have a documented fallback for that dependency. Consider whether better SSL or domain expiration monitoring could have caught a related dependency issue earlier.

Should post-mortems be shared outside engineering?

A public summary (via your status page or a blog post) builds trust with customers for significant outages. Internal versions can include more technical detail than what's published externally.

Handling sensitive or security-related incidents

Security incidents need the same blameless structure, but with additional care around disclosure timing and scope of detail. Draft the technical post-mortem immediately as usual, but hold publication of any external-facing summary until the vulnerability is patched and you've confirmed there's no ongoing exploitation. Internally, apply the same rule as any other incident: describe what happened to the system, not what an individual "should have known."

A few adjustments for security post-mortems:

• Include a section on detection: how was it found (internal review, external report, automated scan), and how long was the exposure window.
• Add a "disclosure timeline" section separate from the incident timeline, tracking when affected users were notified and when any regulatory obligations were met.
• Action items should explicitly include verification steps (e.g., "confirm no unauthorized access occurred via log analysis") in addition to the fix itself.

Turning post-mortems into a knowledge base

Individual post-mortems lose value if they're written once and never referenced again. Build a lightweight index that groups them by root cause category - deployment issues, third-party dependency failures, capacity/scaling, configuration drift, and monitoring gaps. Before rolling out a risky change, a quick search through this index for similar past incidents often surfaces a contributing factor someone already learned the hard way.

Some teams add a short "related incidents" section to new post-mortems, linking back to prior ones with similar root causes. If the same contributing factor appears three times, that's a strong signal the original action item wasn't actually completed, or wasn't sufficient - worth escalating as its own priority rather than filing yet another one-off ticket.

Facilitating a healthy blameless culture over time

Blameless post-mortems fail quietly when leadership reacts punitively to what's written in them, even once. If an engineer is reprimanded after honestly documenting a mistake in a post-mortem, the next post-mortem from that team will be vaguer and less useful, and the one after that will stop mentioning individual actions at all. Protecting the process means explicitly separating post-mortem findings from performance reviews, and modeling that separation visibly from engineering leadership.