--- title: A Painless Guide to Blameless Postmortems description: When things go wrong, managers need to make sure the same problems don't arise again. Here are some guidelines for running a 'blameless postmortem'. image: https://blog.container-solutions.com/hubfs/no-blame-guide-postmortem_sre_cta.png --- Check out our **[Cloud Native Services](https://www.container-solutions.com/services) **and** **book a call with one of our experts today!  [![Container Solutions](https://blog.container-solutions.com/hubfs/CS_blog/logo-main.svg "Container Solutions")](http://container-solutions.com) - share: - [**](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.container-solutions.com%2Fa-painless-guide-to-blameless-postmortems) - [**](https://www.twitter.com/share?url=https%3A%2F%2Fblog.container-solutions.com%2Fa-painless-guide-to-blameless-postmortems) - [**](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.container-solutions.com/a-painless-guide-to-blameless-postmortems) - [**](https://blog.container-solutions.com/a-painless-guide-to-blameless-postmortems#) [![](https://blog.container-solutions.com/hubfs/no-blame-guide-postmortem_sre_blog.png) ](https://blog.container-solutions.com/a-painless-guide-to-blameless-postmortems) [Crisis management](https://blog.container-solutions.com/tag/crisis-management) # A Painless Guide to Blameless Postmortems [Cameron Wood](https://blog.container-solutions.com/author/cameron-wood) ![Cameron Wood](https://blog.container-solutions.com/hubfs/cameron.jpg) August 24, 2020 4 minutes Read Humans are built to make mistakes. It’s how we learn. That’s true whether you work for a small startup or a global enterprise. The trick is to try to avoid making the *same* mistakes, over and over.  No matter how brilliant your engineers are, or how cohesive your team is, things will happen. Things like service outages, or security breaches. Things like, say, the whole world is stuck at home for months and your e-commerce site hasn’t been prepared for the spike in traffic.  At Container Solutions, we hold to a principle of [psychological safety](https://blog.container-solutions.com/what-psychological-safety-means-in-a-cloud-native-organisation)—the idea that no one who works with us will be punished or ridiculed for speaking up or sharing an idea. It’s not just because it makes for a better work environment; it does, but that’s not the point. The point is that when people feel safe, they can solve problems collaboratively, better and faster than if they felt too intimidated to share their thoughts.  This is never more important than [during and after a crisis](https://blog.container-solutions.com/how-to-implement-psychological-safety-in-a-time-of-crisis). That’s where the blameless postmortem comes in. The blameless postmortem is a best practice for Site Reliability Engineering and for IT more generally. It’s also a practice that more organisations need to adopt in order to give themselves every advantage in solving problems. The blameless postmortem helps teams discover what happened when something goes wrong, and why—and how to prevent it from happening again. ## [![firedrills_cta_cre.png](https://no-cache.hubspot.com/cta/default/2252258/353c851d-49ae-43aa-98d1-5b2a6b391df9.png)](https://cta-redirect.hubspot.com/cta/redirect/2252258/353c851d-49ae-43aa-98d1-5b2a6b391df9)Our Postmortems Checklist At Container Solutions, we have created a procedure for running blameless postmortems, both with our customers and internally. Here are our guidelines: **Create a document. **The document can be implemented on a GitLab repository using issues, or in your content/ticket system of choice, Google Docs, Confluence, Jira, etc. It should be opened as soon as possible following an incident, with a title—everything else can be filled in later.  **Include some standard information in the document.** It should always cover: - Who discovered the incident - Impact of the incident - Timeline of the incident - Answers to the [5-Whys, an iterative questioning technique](https://en.wikipedia.org/wiki/5_Whys) - Ways to prevent the incident - Related incidents that happened before **Keep track of the document.** Use GitLab's due date and checklists, a calendar event, or other task tracking tool of choice to ensure this postmortem is not forgotten. **Assign one person responsible for the postmortem. **It does not have to be who found the incident or who solved it, just somebody who facilitates the conversation and makes sure that the postmortem gets done. **Hold regular sharing sessions.** Thank everyone involved in solving and learning from the incident.   **Celebrate your learnings.** Have a small prize (cake at the office, maybe?) every time a postmortem is closed. ## [![New call-to-action](https://no-cache.hubspot.com/cta/default/2252258/e62361f7-6587-407e-82dd-b33617fcbd78.png)](https://cta-redirect.hubspot.com/cta/redirect/2252258/e62361f7-6587-407e-82dd-b33617fcbd78) ## Resources for a Deep Dive The internet is full of information on the subject of blameless postmortems. We recommend two places in particular for a deep dive: [**Code as Craft**](https://codeascraft.com/2016/11/17/debriefing-facilitation-guide/), a project of Etsy, the e-commerce company, includes lots of valuable information about how and why to conduct a blameless postmortem as part of incident response. You can find its open-source repository, including a Debriefing Facilitation Guide, [here](https://github.com/etsy/DebriefingFacilitationGuide). [**The Postmortem**](https://postmortems.pagerduty.com/), an online resource by Pager Duty, is an exhaustive guide to the blameless postmortem, explaining not only the concept but how to introduce it to a team, steps to take, templates to fill out for incident reports, and resources for further reading. There’s also a GitHub [repo](https://github.com/pagerduty/postmortem-docs).  --- You can find all of our information about SRE and CRE in one place. Click [here](https://www.container-solutions.com/learn-with-cs/sre).[![New call-to-action](https://no-cache.hubspot.com/cta/default/2252258/6060646b-cfc6-40f8-8285-e08f1c4978e1.png)](https://cta-redirect.hubspot.com/cta/redirect/2252258/6060646b-cfc6-40f8-8285-e08f1c4978e1) [### Cloud Native and Wishful Thinking—or, How to Avoid Buying Co... ](https://blog.container-solutions.com/cloud-native-transformation-and-wishful-thinking) [![prev-arrow](https://cdn2.hubspot.net/hubfs/3842749/Wow%202019/Images/left-arrow.png) Previous article](https://blog.container-solutions.com/cloud-native-transformation-and-wishful-thinking) [ Next article ![next-arrow](https://cdn2.hubspot.net/hubfs/3842749/Wow%202019/Images/right-arrow.png) ](https://blog.container-solutions.com/gitops-limitations) [ ### GitOps: The Bad and the Ugly ](https://blog.container-solutions.com/gitops-limitations) Comments Leave your Comment ![cs-logo-white](https://blog.container-solutions.com/hs-fs/hubfs/cs-logo-white.png?width=150&height=61&name=cs-logo-white.png "cs-logo-white") #### **Talk to sales** [info@container-solutions.com](mailto:info@container-Solutions.com) #### Stay In Touch - [**](https://www.linkedin.com/company/container-solutions/) - [**](https://twitter.com/containersoluti) © 2024 Container Solutions