Free Engineering Postmortem Template (Decision-Focused)

A decision-focused postmortem is a postmortem that puts the decision history of an incident at the center of the analysis. The classic postmortem template covers the timeline, root cause, and action items. It is fine, and most teams have one. What it misses is the structure of the decisions made during the incident — who decided what, when, with what information, and how confidently. Those decisions are where teams get faster, not the timeline.

The template below is what a decision-focused postmortem looks like. It is not a replacement for the standard postmortem; it is an enrichment. The first three sections look familiar. The middle sections are where the format earns its keep — they extract the decisions from the timeline and ask the harder questions about each one.

When to use it

• Any Sev-1 incident or any Sev-2 longer than two hours.
• Any incident where the team felt slower than it should have been.
• Any incident where multiple teams had to coordinate.
• Any time you suspect the next incident will repeat the same mistakes.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

POSTMORTEM — [INC-NNN]
Date of incident:  [date]
Date of doc:       [date]
Author:            [name]
Severity:          [Sev-?]
Duration:          [N] minutes
Customer impact:   [description]

ONE-PARAGRAPH SUMMARY
  Plain-language description of what happened, end to end.

TIMELINE
  HH:MM  Event
  HH:MM  Event
  HH:MM  Event
  (Use UTC; include who acted at each step.)

WHAT HAPPENED
  Mechanically. The system-level chain of events.

WHY IT HAPPENED
  Contributing factors, not "root cause." Real incidents have layers.
    - [factor]
    - [factor]
    - [factor]

KEY DECISIONS DURING THE INCIDENT
  For each significant decision made during the response:

  Decision 1: [what was decided]
    Who:        [name]
    When:       [HH:MM]
    Confidence: [low / medium / high]
    Based on:   [what info was available]
    In retrospect: [right / wrong / right for wrong reasons]
    What would have helped at the time: [signal that was missing]

  Decision 2: [what was decided]
    ...

DECISIONS WE AVOIDED
  Decisions that were on the table during the incident but did not
  get made — escalations not called, rollbacks not done.
    - [decision] — what would have been different if we had?

WHAT WORKED
  Specific. Not "the team was great." Examples:
    - The runbook for [system] had the exact command we needed.
    - [name] was paged correctly within [N] minutes.

WHAT DID NOT WORK
  Specific. Not "communication was bad." Examples:
    - The dashboard for [signal] did not exist; we built it during
      the incident.
    - We thought [system] was owned by [team] but it was unowned.

ACTION ITEMS
  Each one: owner, deadline, concrete.
    [ ] [action] — owner [name] — by [date]
    [ ] [action] — owner [name] — by [date]
    [ ] [action] — owner [name] — by [date]

LESSONS FOR NEXT TIME
  Two or three sentences. The shape of the lesson, not the wording
  of every action item.

How to use it well

• Decisions, not personalities. The decision section is about the decisions and the information available at the time. It is not about whether anyone made the wrong call. A correct decision with bad information is still a correct decision; a lucky decision with no information is not a good decision.
• "Decisions we avoided" surfaces the highest-leverage learnings. Incidents lengthen most often because of escalations that did not happen and rollbacks that were debated for too long. Naming the avoided decisions is the way to see the pattern.
• Contributing factors, not root cause. Real incidents have multiple factors. The "five whys" trick produces a single root cause that is rarely the whole truth. List the factors; let the team look at the set.
• Action items must have owners and deadlines. An action item without a name and a date is not an action item. The team will not do it. The postmortem becomes archaeology.
• Run the lessons through the quarterly decision review. Postmortems decay if they live alone. Bringing them to the quarterly review keeps the lessons in circulation.

What to skip

Skip blame language entirely. Not because blame is unprofessional — though it is — but because blame produces worse data. Engineers in a blameless culture document decisions honestly; engineers in a blame culture document defensively. The decision section depends on the former.

Skip writing postmortems for every minor alert. The format has overhead. Save it for Sev-1, long Sev-2, and any incident that crosses team boundaries. Tier-3 noise does not need a decision review.

Frequently asked questions

Is this template free?

Yes. The structure above is the whole template. Most teams keep postmortems in a /postmortems folder per service or per year.

Can I edit it?

Yes. The Key Decisions section is the load-bearing part; the rest can be tuned. Many teams add a Customer Communication row for incidents with external impact.

Do I need to give my email?

Not for the template. The download is a formatted Notion version; the email is only for our newsletter list.