On a three-person team, "full SRE postmortem process" is a joke. Skipping learning entirely is how the same outage repeats in six weeks. The middle path is a short, honest writeup while memory is fresh.
What blameless actually means
It does not mean "nobody made a mistake." It means you assume people acted with the information and tools they had, and you ask what would make the next person succeed. The deploy button without a maintenance window, the alert nobody trusted, the missing runbook: those are the villains worth naming.
If someone was reckless on purpose, that is a management conversation offline, not a public pile-on in the doc.
The one-pager
Aim for something you can finish in an hour:
- Summary: one paragraph a customer could almost read.
- Timeline: detect, ack, mitigate, resolve (with timezones).
- Impact: who felt it, for how long.
- Triggering factors: what broke, what we believed that was wrong.
- What went well: so you keep those habits.
- Action items: each with an owner and a date. Three is plenty. Zero is failure.
No architecture novel. No screenshots of Slack fights.
Timing
Draft within 48 hours while the night is still vivid. Share with the people who were paged. Publish internally (and a customer-facing summary if the incident was public). Then do the actions; a postmortem folder of unfinished TODOs is worse than no postmortem.
Facilitation on a tiny team
Whoever was not deep in the fix can drive the doc so the primary responder can rest. Keep the meeting to thirty minutes or skip the meeting and async the draft. The output matters more than the ritual.
Close the loop
If detection was late, fix monitors. If status was silent, fix the update habit (what to say). If the page was ignored, fix trust. The postmortem is how monitoring and on-call earn their keep, not a homework assignment from a blog about Google.