Post-mortems
What happened, why, and what actually changed because of it.
Incidents & On-Call → Post-mortems turns an incident into something the organisation learns from.
When
Within a working day. Memory decays fast and the timeline does not capture why somebody tried something.
Blameless, and what that means
Blameless does not mean "do not say who did what". It means the analysis stops at why the system allowed it, not at who did it.
"Somebody deployed a bad config" is not a finding. "A config that would break production could be deployed without validation, and the validation that exists runs after the deploy" is a finding, because it can be fixed.
Structure
| Section | Contains |
|---|---|
| Summary | Three sentences a stranger can follow |
| Impact | Who, how many, for how long, what it cost |
| Timeline | Pre-filled from the incident |
| Detection | How did we find out — and how should we have? |
| Root cause | Why it was possible, not who did it |
| Resolution | What made it stop |
| What went well | Genuinely. It identifies what to protect |
| Action items | With an owner and a date |
Detection deserves its own section
The most valuable question in most post-mortems is not "why did it break" but "why did we find out the way we did".
If a customer told you, that is a monitoring gap, and it is usually cheaper to fix than the underlying bug — and it applies to every future incident, not just this one.
Action items
An action item without an owner and a date is a wish.
AccelerUp tracks them to completion and shows the outstanding ones in the post-mortem list. An organisation with thirty open action items from eight incidents is telling itself something.
AI assistance
The Copilot can draft a post-mortem from the incident timeline, the alerts, the deploys and the change feed.
A draft, not a document. It is good at the timeline and the impact arithmetic — the mechanical parts — and it cannot know why somebody tried what they tried. Read every line before publishing, especially the root cause.
Publishing
A post-mortem can be published to a public URL for customers or partners. Published versions are separate from the internal one, so internal detail is not exposed by accident.
Lessons
Post-mortems → Lessons aggregates findings across incidents. Three post-mortems that each blamed a different service but all say "we found out from a customer" are one problem, and only visible from the aggregate.
Where this behaviour lives: frontend/src/app/postmortem/, backend/internal/handler/postmortem_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Incidents and on-call — Turning a reading into a page, and a page into a resolved incident.