Skip to content
Folio

Incident Postmortem Template (Markdown)

A blameless incident postmortem template in plain Markdown. It records the impact, a UTC timeline, the causes (plural), what went well and badly, and action items with an owner, a type and a due date. Copy it, download the .md file, or keep it with your runbooks.

Free to use, no attribution required (CC0).

Open in Folio demo

Postmortem: {{Short incident title}}
Incident ID {{INC-123}}
Severity {{SEV1 / SEV2 / SEV3}}
Status {{Draft / In review / Final}}
Date {{YYYY-MM-DD}}
Duration {{N h M min}} (from start of impact to resolution)
Authors {{Names}}
Incident commander {{Name}}
Reviewers {{Names}}

Blameless: describe what people did with the information they had at the time. No names of "culprits".

Summary

Three to five sentences: what happened, who was affected, how it was fixed, the main lesson.

{{...}}

Impact

  • Users or customers affected: {{number or percentage}}
  • What they experienced: {{errors, slowness, data issue}}
  • Business impact: {{lost transactions, SLA or SLO breach, support tickets}}
  • Data loss: {{None / description}}

Timeline (UTC)

Use one timezone. Mark the four key moments in bold: impact started, detected, mitigated, resolved.

Time (UTC) Event
{{HH:MM}} {{Change deployed / trigger}}
{{HH:MM}} Impact started
{{HH:MM}} Detected by {{alert / customer / engineer}}
{{HH:MM}} {{On-call acknowledged; incident declared}}
{{HH:MM}} {{Action tried and its result}}
{{HH:MM}} Mitigated by {{action}}
{{HH:MM}} Resolved; monitoring

Time to detect: {{N min}} · Time to mitigate: {{N min}} · Time to resolve: {{N min}}

Detection

  • How did we find out? {{alert, customer report, engineer}}
  • Was it fast enough? If not, what would have caught it earlier?

Causes

Several contributing factors are normal. Keep to what the evidence supports.

  • Trigger: {{The event that started it}}
  • Conditions that made it possible: {{...}}
  • Defences that did not stop it: {{tests, alerts, limits, reviews}}
flowchart LR
    A[Trigger] --> B[Condition 1]
    B --> C[Condition 2]
    C --> D[Customer impact]
    E[Missing safeguard] -.-> D
Five whys
  1. Why did {{impact}} happen? Because {{...}}
  2. Why {{...}}? Because {{...}}
  3. Why {{...}}? Because {{...}}

Resolution and recovery

{{What stopped the impact, what restored normal service, how we verified.}}

What went well

  • {{...}}

What went badly

  • {{...}}

Where we got lucky

  • {{Something that could have made it worse but did not}}

Action items

Type: Prevent (stop it happening), Detect (find it sooner), Mitigate (reduce the damage). Every item has one owner and a date.

# Action Type Owner Priority Due Ticket
1 {{Specific change}} Prevent {{Name}} P1 {{YYYY-MM-DD}} {{link}}
2 {{...}} Detect {{Name}} P2 {{YYYY-MM-DD}} {{link}}
3 {{...}} Mitigate {{Name}} P2 {{YYYY-MM-DD}} {{link}}

Lessons

  • {{What this changes in how we build, deploy or operate}}

Supporting material

  • Dashboards and graphs: {{links}}
  • Chat transcript: {{link}}
  • Related runbook: {{link}}
  • Related postmortems: {{links}}

Want to see it as a real wiki page? Open this template in the Folio demo, where it is a normal Markdown page.

How to use it

  1. Step 1: Start within a few days, while memories are fresh. Create the document from the template, name an owner, and paste in the raw data: alerts, chat logs, deployment times.

  2. Step 2: Build the timeline first, then the causes. List what happened in UTC, then ask "why" until you reach causes you can fix. Expect several contributing factors, not one culprit.

  3. Step 3: Review with the people involved, then track the actions. Agree the wording in a short meeting, create tickets for the action items, and link them. Close the postmortem only when the actions are done or consciously dropped.

What makes a good postmortem

It is blameless. The question is "how did the system let this happen?", not "who did it?". People who fear blame hide details, and the details are the lessons. Describe actions in terms of the information people had at the time.

It has a timeline you can trust. One timezone (UTC), timestamps from logs and chat, and four moments marked: start of impact, detection, mitigation and resolution. The gap between impact and detection often matters more than the cause.

It finds contributing factors, not a single root cause. Complex failures have several. List the trigger, the conditions that made it possible, and the defences that failed to stop it. Keep it to what you can support.

Its actions are specific, owned and typed. "Improve monitoring" is not an action. "Add an alert for queue depth above N, owner Name, due date" is. Mark each action as prevent, detect or mitigate, and keep the list short enough to finish.

More templates

RunbookTrigger, triage flowchart, exact commands with expected output, rollback and escalation.Release notesHighlights, new, improved, fixed, breaking changes and upgrade steps for each release.Meeting notesDecisions and action items first, raw discussion below. One owner and a date per action.
All templates

Questions

What is a blameless postmortem?
A review of an incident that focuses on the conditions, processes and tooling that allowed it, not on the people who were involved. The goal is learning and prevention, so the document is written so that engineers can be honest in it.
When should we write a postmortem?
When an incident meets criteria you agree on in advance: customer impact above a threshold, data loss, a page for on-call, a manual intervention, or anything that taught the team something surprising. Decide the criteria before you need them.
How long should a postmortem take?
Gather data and draft within a few days of the incident, and hold the review within the following week. The document should be as short as the incident allows: a minor incident may need one page.
Who should read postmortems?
The team involved, adjacent teams, and anyone who runs a similar system. Share them widely inside the company. Share outside only after review, with customer-safe wording.
What is the difference between a postmortem and a retrospective?
A postmortem examines a specific incident: what happened, why, and how to prevent a repeat. A retrospective reviews a period or a project and how the team worked. A postmortem may lead to process changes that you then discuss in a retrospective.

Updated 11 October 2026.

Keep postmortems searchable, next to the runbooks

In Folio a postmortem is a Markdown page in Git. Keep them in an incidents/ folder, link each one to the runbook it changed, and use the built-in search or the assistant to answer "have we seen this before?". Action-item checkboxes stay in the document, and the history shows how the story was revised.

Open in Folio demoInstall FolioFolio on GitHub