How do you run a blameless post-mortem after an incident?

Question

Accepted Answer

A **blameless post-mortem** treats an incident as a failure of *systems and conditions*, not of people. The question is never "who broke it" but "how did our systems let a reasonable person cause this, and how do we make it impossible next time?"

## The process

1. **Build a timeline.** Reconstruct what happened minute by minute: detection, escalation, mitigation, resolution. Stick to facts.
2. **Find contributing factors.** Most incidents have several. Use techniques like **5 Whys** to move past the surface symptom to the **root cause** — missing alerts, a brittle deploy, an unclear runbook.
3. **Produce action items.** Each one is **concrete, owned, and has a due date**. "Be more careful" is not an action item; "add a pre-deploy migration check" is.
4. **Share widely.** Publish the write-up so the whole org learns, not just the people in the room.

## Blameless in practice

- Describe **what** happened and **why it made sense at the time**, not **who** to fault.
- Assume everyone acted reasonably with the information they had.
- If a single human action could take down production, that's a **system gap**, not a personal failing.

## Why psychological safety matters

The moment people fear being blamed, they hide details, downplay their role, and the real causes stay buried. **Psychological safety drives honesty**, and honesty is the only thing that produces fixes that actually stick.

## Why it matters

Incidents are expensive tuition — a blameless post-mortem is how you actually get the lesson. Done well, the same outage doesn't recur, the system gets more resilient with each failure, and the team trusts that owning up to a mistake makes things better, not worse.