> ## Documentation Index
> Fetch the complete documentation index at: https://internal.september.wtf/llms.txt
> Use this file to discover all available pages before exploring further.

# Postmortems

> Blameless incident reviews. How we run them and how we file them.

A postmortem is a written record of what went wrong and what we learned. We
write them blamelessly — not because the people involved didn't make
mistakes, but because the goal is to fix the system, not the people. A
postmortem that names individuals as the failure point will not produce
durable improvements. A postmortem that names the gaps in process, tooling,
and design will.

## When to write one

| Severity                                | Postmortem?               |
| --------------------------------------- | ------------------------- |
| Sev1 (customer-impacting outage)        | Required                  |
| Sev2 (degraded service, partial outage) | Required                  |
| Sev3 (caught early, no customer impact) | Encouraged                |
| Near-miss                               | Encouraged if interesting |

## When to skip

You don't need a postmortem for:

* A single dropped request that retried and succeeded.
* A flaky test.
* An alert that fired but was misconfigured (file an alerting fix instead).

If in doubt, write one. They take an hour and save weeks.

## The blameless rule

In the postmortem document:

* Refer to people **by role**, not by name. "The on-call engineer" not "Alice."
* Describe **decisions**, not motivations. "The engineer rolled forward
  rather than back" not "the engineer panicked and rolled forward."
* Describe **system behavior**, not human behavior. "The deploy script did
  not have a dry-run mode" not "the deployer ran the wrong command."

This isn't about being polite. It's about producing accurate analysis.
"Operator error" is a non-explanation that ends investigation. "The
deployment system did not require confirmation before destroying the prod
database" is the start of a fix.

## Lifecycle

1. **Incident closes.** The on-call engineer files a stub postmortem within
   24 hours.
2. **Author named.** One person owns drafting. Usually whoever was on-call.
3. **Draft within 5 working days.** Cover: summary, impact, timeline, root
   cause, trigger, detection, resolution, action items, what went well,
   what went badly, lessons. Use roles, not names.
4. **Review.** Schedule a 30-minute review meeting with everyone involved
   plus the service owner. The review's job is to challenge the timeline and
   the action items, not to assign blame.
5. **Action items dated and owned.** Every action item gets an owner and a
   target date. Action items without owners and dates don't ship.
6. **Publish.** Postmortems live in `operations/postmortems/`. Internal-only.
   We circulate them in #engineering.
7. **Track follow-through.** Review action item status weekly until all are
   closed.

## Where they live

`operations/postmortems/YYYY-MM-DD-short-slug.mdx`.

## What we don't do

* We don't censor postmortems. The internal version is honest.
* We don't make postmortems performance-review inputs. (If they were, no one
  would write honest ones.)
* We don't write postmortems for the customer. If we owe a customer a public
  RCA, write it separately and link from here.