Postmortems: Support
"How we run blameless, action-oriented reviews for major incidents and repeated bugs."
Why this exists
A postmortem without action items is just a meeting. We run reviews to find system failures rather than human mistakes, and to write concrete tasks that make the application resilient. Otherwise, we fix the same bugs repeatedly.
Operational Flow
Trigger criteria: Conduct a postmortem for P0 incidents, client escalations, or bugs reported three or more times in a sprint.
Assign a facilitator: Appoint a project lead or senior engineer who was not directly involved in the incident to run the discussion.
Document within five days: Use the Notion template to write a Timeline, Root Cause, Contributing Factors, Impact, and Action Items.
Create specific tasks: Assign every action item to a person and set a deadline. 'Fix Sentry error triggers' is better than 'improve logging'.
Remain blameless: Focus on the system. If you name a teammate, highlight what they did to resolve the issue, not what they did wrong.
Share the results: Post the review in Notion and share the link with the client if the incident impacted their business.
What good looks like
- A P0 issue ends on Tuesday. By Friday, we complete the review, finish two of three action items, and send the summary to the client.
- A recurring bug is analyzed in a postmortem, the root cause is traced to a missing index, and the ticket is closed permanently.
- A new developer reads past incident logs during onboarding and understands how the architecture changed to prevent errors.
What NOT to do
- Don't write 'engineer error' as the root cause. Explain why the system allowed the mistake to impact production.
- Don't write action items without assigning them to an owner. 'Improve tests' will never get done.
- Don't hide postmortems from clients. Sharing reviews transparently builds trust.
- Don't schedule the postmortem meeting more than five business days after the event. Memories fade quickly.
The hardest part of a postmortem is avoiding blame. When a client is angry about an incident, it is tempting to blame a single decision by one developer. That is lazy. Developers make the best choices they can with the tools and timelines they have. The postmortem must find out why those tools or timelines failed them. One review showed that our staging environment had drifted so far from production that local testing was useless. The infrastructure was the problem, not the engineer.
Action items are the only measure of a postmortem’s success. Vague next steps (like ‘we should be more careful during deploys’) are useless. Write specific actions, assign a name, and set a date. If a task does not start with a verb and end with a deadline, rewrite it. Keep the reviews in Notion and track the action items in Linear to close the loop.