dawka
Sign inCreate a document
← All templates

Template preview · Software

Incident postmortem

Learn from an incident without turning the record into blame.

A blameless postmortem for a fictional service disruption.

Sample purpose

Learn from an incident without turning the record into blame.

Audience: SRE, Engineering manager
Structure
4 sections
Criteria
16
Sources
12
Watches
3
Default approach
Review first
See the sample

Set the purpose first. Then change every section, criterion, and agent setting before anything runs.

Fictional sample

Structure and criteria

Sample content shows the shape of a useful document. Copying it is optional.

  1. 01

    Incident summary

    State customer impact and duration plainly.

    Review first

    Criteria

    • Gives start and end times in one format (2026-02-18T09:02Z)
    • Gives the affected count or share (84 customers)
    • States whether data was lost, delayed or corrupted
    • Names systems, not people

    Sources

    Sample content

    On 2026-02-18, Lantern Cloud invoice exports were delayed for 47 minutes after a queue consumer deployment. 84 fictional customers received exports late; no invoices were lost.

  2. 02

    What happened

    Reconstruct meaningful events and decisions.

    Review first

    Criteria

    • Each event has a timestamp in one format, with no gap over 10 minutes during the incident
    • Detection is separate from onset
    • Recovery event is verified, e.g. test export succeeded
    • Observations (alert value 45 s) are separate from guesses

    Sources

    Watches

    • Follows Incident summary

    Sample content

    1. 09:02 · DeploymentConsumer version 3.4 released.
    2. 09:11 · AlertQueue delay alert fired.
    3. 09:49 · RecoveryRollback drained backlog.
  3. 03

    Contributing factors

    Explain conditions that made the incident more likely or harder to resolve.

    Review first

    Criteria

    • Each factor is a condition that existed before the incident, not an action during it
    • Effect ties the factor to a timeline impact (nine-minute correlation delay)
    • Each factor can be fixed with a process, test or system change
    • No factor names a person

    Sources

    Watches

    • Follows What happened

    Sample content

    FactorEffect
    Rollback rehearsal omitted queue backlogTeam lacked a quick drain estimate.
    Alert lacked deployment annotationCorrelation took nine minutes.
  4. 04

    Follow-up actions

    Turn learning into owned work with verification.

    Manual

    Criteria

    • Owner is a named person or role with authority to complete it
    • Due date is a calendar date or tied milestone
    • Completion evidence is testable (backlog rollback drill passes)
    • Each action traces to a contributing factor

    Sources

    Watches

    • Follows Contributing factors

    Sample content

    • ☐ Omar adds backlog rollback drill by 2026-03-12
    • ☐ Tess annotates deployment alerts by 2026-03-05