# How to write a blameless incident postmortem > A blameless postmortem explains what broke, why and what changes. Learn the sections, how to write the timeline and root cause, and an example. A postmortem explains what broke, why it broke and what the team will change so it does not break the same way. It looks at the system and the process, not at who was on call. Web page: https://kansohq.app/guides/how-to-write-a-postmortem Updated: 5 October 2026 ## What a postmortem is An incident postmortem, or incident review, is a written account of something that went wrong in production. It exists to learn, not to assign fault. A team that punishes the person nearest the failure learns to hide failures. A team that studies them gets safer. ## Write it soon, and write it together Start within a few days, while the details are fresh. The people who were involved should write or review it together. One person drafts, the others correct. The first draft is almost always missing something that someone else remembers. ## The sections 1. **Summary:** what broke, who was affected and for how long, in two or three sentences. 2. **Impact:** when it started, when it was detected, when it was resolved, who was affected and how severe it was. 3. **Timeline:** what happened, what was seen and what was done, in time order, in plain words. 4. **Root cause:** the chain of causes, down to the one that would have prevented the incident if it had been removed. 5. **What went well, what went badly and where we got lucky:** the last one is the most honest. 6. **Actions:** concrete changes, each with an owner and a date. ## Finding the root cause Ask “why?” until the answer is something you can change. “The deploy broke the database” is a symptom. “The migration was run without a dry run, because the dry run step is not in the release checklist” is a cause you can fix. There is rarely one cause. Write the chain, and put the actions at the links you can break. **A short timeline** > **14:02** Error rate for sign-ups rises to 40 percent. An alert fires. > **14:09** On-call finds the new release is timing out on a slow query. > **14:15** The release is rolled back. Errors fall. > **14:30** Sign-ups are normal. Incident closed. ## Write actions that will happen - Each action has an owner and a date, and goes on the team’s board, not only in the document. - Prefer changes that make the failure harder to repeat over reminders to be careful. - Keep the list short. Three actions that get done beat twelve that do not. ## Mistakes to avoid - Naming a person as the cause. - Stopping at the first answer to “why?”. - Writing it, filing it and never reading it again. Review old postmortems in the retrospective. ## How serious was it? Agree a small scale for severity before you need it, so the first minutes of an incident are not spent arguing about words. | Level | What it looks like | What follows | | --- | --- | --- | | 1 | The product is down, or data is lost or exposed | A full postmortem, reviewed by the whole team | | 2 | A main feature is broken for many people | A postmortem, shared with the team | | 3 | A feature is degraded or broken for a few people | A short written note and a task | | 4 | A minor problem with a workaround | A task on the board | ## A short example **Sign-up errors, 14 October** > **Summary:** For 13 minutes, 40 percent of sign-ups failed with an error. > **Root cause:** a release added a query that was slow on large accounts. The release process had no step that tested a large account. > **What went well:** the alert fired within a minute, and the rollback took four minutes. > **Where we got lucky:** it happened on a quiet afternoon. > **Actions:** add a large-account case to the release checklist (QA lead, by Friday); alert when sign-up errors pass 5 percent (on-call engineer, by next Wednesday). ## Share what you learn A postmortem helps only the people who read it. Send it to the whole team, keep every one in one place and look back through them in the retrospective. Patterns show up across incidents that no single review can see: the same missing test, the same confusing alert, the same unowned system. ## A postmortem in Kanso The [incident postmortem template](https://kansohq.app/templates/incident-postmortem.md) has the summary, impact table, timeline, root cause and actions ready. Turn each action into a card on the [board](https://kansohq.app/product/boards.md), and link the incident thread from [team chat](https://kansohq.app/product/chat.md) so the conversation and the review stay together. ## Questions ### What is a blameless postmortem? A postmortem that looks at what the system and the process allowed to happen, instead of who made the mistake. People are more honest about failures when they do not fear being blamed. ### How soon after an incident should a postmortem be written? Start within a few days, while memories are fresh, and finish within a week or two. ### What should a postmortem include? A summary, the impact, a timeline, the root cause, what went well and badly, and actions with owners and dates. ### Do all incidents need a postmortem? Write one for any incident that affects customers, loses data or surprises the team. Smaller ones can get a short note. ## Keep reading - [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through. - [How to run a bug tracking board that stays tidy](https://kansohq.app/guides/bug-tracking-board.md): Run a bug tracking board that does not turn into a graveyard: what a bug card needs, how to triage, how to rank bugs and when to close them. - [What is an architecture decision record (ADR)?](https://kansohq.app/guides/what-is-an-adr.md): An architecture decision record (ADR) is a short note on a decision, why it was made and what follows. Learn the format, when to write one and examples. - [Blameless incident postmortem template | Kanso](https://kansohq.app/templates/incident-postmortem.md): A blameless incident postmortem template with a summary, impact table, timeline, root cause and actions. Copy it, or start it in Kanso. - [Retrospective template for software teams | Kanso](https://kansohq.app/templates/retrospective.md): A retrospective template with what went well, what did not, what we learned and what we will change, each change with an owner. Copy it, or start it in Kanso. ## Parts of Kanso used - [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release. - [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done. - [Kanso Chat](https://kansohq.app/product/chat.md): Channels and direct messages that link straight to the task, page or release being discussed. [Kanso home, with plans and prices](https://kansohq.app/index.md)