Guide
Postmortems
A postmortem turns one incident into lessons the whole team keeps. It's for learning, not for finding who was at fault.
When to write one
After any incident customers felt, that needed several teams, or that could happen again. Near-misses are worth one too.
Start within a day or two of resolving, while memory is fresh, and name a postmortem runner to get it written: /inc role postmortem_runner @user.
Facts first, then why
Reconstruct what happened before deciding why. The timeline, key times, impact, detection, root cause and resolution live on the incident, and the postmortem shows them as they are, so nobody copies them over.
Your workspace's default template follows the Google SRE book: those facts, then contributing factors (5 Whys), what went well, what went wrong and where you got lucky. Admins edit templates in Settings.
Keep it blameless
Ask how the system let it happen, not who did it. People are honest when they aren't on trial.
Not “Ana deployed broken code”, but “nothing tested the change before it shipped.”
Turn lessons into work
A lesson only counts once someone owns it. Add each fix with /inc remediation, give it an owner, and keep it small and specific: “be more careful” isn't one. With Jira connected, each becomes a Jira issue, and its status syncs back.
Review, then publish
1Draft
/inc postmortemstarts one, or Start postmortem on the resolved notice. A checklist shows what's still empty.2In review
Ready for the team to read. Back to draft if it needs more work.
3Published
Final, and announced once. Answers can still be corrected.