methodatlas
Playbook

Learn from Incident

Move from scattered logs and memories to timeline, learning points, and concrete improvements.

Steps4 methods
Time2-6 h
FormatHybrid
Outcome

A blameless postmortem with timeline, contributing factors, actions, and follow-up.

At the end you have

Incident TimelineCausal Factor MapBlameless PostmortemUpdated Runbook

Decision point

You can decide which systemic improvements are prioritized and which operational adjustments are needed immediately.

Next step

Track actions with owners, update runbooks or alerts, and check the learning effect in the next review.

Ideal for

  • SRE and DevOps incidents
  • Critical production disruptions
  • Recurring operational problems

Not good for

  • Acute incident command
  • Blame-oriented escalations
Preparation

What should be clear before you start

Roles

  • Incident lead or facilitator
  • Involved engineers and operations roles
  • Service owner or product responsible

Inputs

  • Logs, alerts, and chat history
  • Times of important decisions
  • Known impact on users or operations

Setup

  • Set a blameless frame
  • Collect sources upfront
  • Clarify review goal and follow-up mechanism
Flow

Method path

4 methods
  1. 1DevOpsIncident Timeline

    Incident Timeline Analysis

    Which evidenced event sequence explains detection, response, and impact without projecting later knowledge into earlier decisions?

    Why this step?

    The timeline creates a shared, verifiable picture of what was observed, decided, and done when.

    The timeline then allows contributing factors to be derived instead of single causes.

    Paper illustration for Incident Timeline Analysis.
  2. 2OperationsCausal Factor Map

    Causal Factor Analysis

    Which events and conditions demonstrably contributed to the undesired outcome, and how are they linked in time and causality?

    Why this step?

    Causal factor analysis separates visible triggers from conditions, interactions, and gaps in the system.

    The factors are then moved into an actionable learning and improvement document.

    Paper illustration for Causal Factor Analysis.
  3. 3DevOpsPostmortem

    Blameless Postmortem

    Which conditions enabled the incident, and how do we reduce recurrence or impact?

    Why this step?

    The postmortem bundles learning, impact, factors, and actions without blame.

    The actions lead to concrete changes in runbooks, alerts, or processes.

    Blameless Postmortem workspace showing the question, observations, and next decision.
  4. 4OperationsUpdated Runbook

    Runbook

    Can an authorized responder under pressure safely tell when and how to use this procedure?

    Why this step?

    The runbook makes recurring response steps explicit and reduces uncertainty in the next incident.

    The updated runbook is operationalized and checked in the next incident or game day.

    Runbook workspace showing the question, observations, and next decision.
Completion criteria
Templates

Artifacts for this playbook

Artifacts stay collapsed until you actually need them.

MarkdownShow template

Incident Timeline

Chronological template for incident reconstruction with sources and uncertainty.

# Incident Timeline

**Incident:** ...
**Period:** ...
**Sources:** logs, alerts, chat, tickets

| Time | Event | Source | Confidence | Note |
|---|---|---|---|---|
| HH:MM | | | high/medium/low | |

## Observed delays

- ...

## Open gaps

- ...

## Learnings

- ...
MarkdownShow template

Blameless Postmortem: Worksheet

Prepare Blameless Postmortem with a clear question, roles, and sources.

# Blameless Postmortem: Worksheet

## Question
To be confirmed

## Desired outcome
To be confirmed

## Scope
Plan the full method
Time: Set according to scope and available evidence

Complete this worksheet on paper or in your own document during the work.

## Preparation for this scope

### Method setup
- **Materials:** Shared workspace, accessible sources, and a decision log.
- **Roles:** Incident responders · facilitator · action owners
- **Advance information:** Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
- **Overall time needed:** 60–90 minutes after stabilization; evidence preparation and action tracking are separate.
- **Setup:** Create a shared version. Label facts, assumptions, and decisions separately.

### Prepare for the work steps

#### Facts: Set learning frame and evidence
- Resolved incident and review purpose

#### Timeline: Reconstruct the timeline
- Logs, status updates, and knowledge at the time

#### Conditions: Examine conditions
- Timeline, system conditions, and safeguards

#### Actions: Track actions
- Learning, action tracker, and owners


## Timeline, conditions, and actions

### Impact
Record incident ID, impact, period, and review purpose.

...

### Timeline
Order events with source and contemporaneous knowledge.

...

### Conditions
Record process, tool, and system conditions plus uncertainty.

...

### Actions
Add prevention/detection/mitigation action, owner, and date.

...

Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.

[Using SRE to meet reliability challenges · Google Cloud](https://cloud.google.com/blog/products/management-tools/meeting-reliability-challenges-with-sre-principles)


## Facts: Set learning frame and evidence
Expected artifact: Bounded incident with preserved evidence

Bounded incident with preserved evidence

Entry:

...

- [ ] Is immediate response complete?

## Timeline: Reconstruct the timeline
Expected artifact: Evidence-based timeline

Evidence-based timeline

Entry:

...

- [ ] Are facts separated from interpretation?

## Conditions: Examine conditions
Expected artifact: Systemic contributing conditions without blame

Systemic contributing conditions without blame

Entry:

...

- [ ] Are multiple contributing conditions examined?

## Actions: Track actions
Expected artifact: Trackable improvement actions

Trackable improvement actions

Entry:

...

- [ ] Are actions verifiable and tracked?

## Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/blameless-postmortem/run-sheet
MarkdownShow template

Runbook: Worksheet

Prepare Runbook with a clear question, roles, and sources.

# Runbook: Worksheet

## Question
To be confirmed

## Desired outcome
To be confirmed

## Scope
Plan the full method
Time: Set according to scope and available evidence

Complete this worksheet on paper or in your own document during the work.

## Preparation for this scope

### Method setup
- **Materials:** Shared workspace, accessible sources, and a decision log.
- **Roles:** On-call expert · service owner · reviewer
- **Advance information:** Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
- **Overall time needed:** Maintain as ongoing practice; retest after changes and during agreed operational exercises.
- **Setup:** Create a shared version. Label facts, assumptions, and decisions separately.

### Prepare for the work steps

#### Trigger: Define trigger and scope
- Service, alert, trigger, and scope

#### Procedure: Write safe steps
- Access, read-only checks, and expected results

#### Escalation: Define escalation and recovery
- Escalation, approval, rollback, and success criterion

#### Maintenance: Exercise and maintain
- Exercise outcome, owner, and review date


## Trigger, diagnosis, escalation, and recovery

### Trigger
Define signal, service, prerequisites, and non-applicability.

...

### Diagnose
List read-only checks with expected results.

...

### Action
Record authorization, escalation contact, and recovery path.

...

### Verify
Record tester, exercise date, owner, and freshness.

...

Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.

[Being On-Call · Google SRE Workbook](https://sre.google/workbook/on-call/)


## Trigger: Define trigger and scope
Expected artifact: Measurable trigger and procedure boundary

Measurable trigger and procedure boundary

Entry:

...

- [ ] Is the trigger measurable?

## Procedure: Write safe steps
Expected artifact: Validated safe diagnostic sequence

Validated safe diagnostic sequence

Entry:

...

- [ ] Can each step be executed with safe context?

## Escalation: Define escalation and recovery
Expected artifact: Escalation, rollback, and success criteria

Escalation, rollback, and success criteria

Entry:

...

- [ ] Is there a clear stop point?

## Maintenance: Exercise and maintain
Expected artifact: Exercised runbook with review ownership

Exercised runbook with review ownership

Entry:

...

- [ ] Is the procedure current and tested?

## Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/runbook/run-sheet