methodatlas
Method guideOperations

Runbook

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityLow
Time20-60 min
Participants1-4
FormatAsync
MaturityCanonical
Prepare plan
01

Prerequisite

What needs to be finished first

Complete firstClear scope

A recurring operational procedure with a defined trigger and expert owner for validation.

Without a boundary, data, perspectives, or flows become mixed.
Complete firstAccess to evidence

Relevant people and sources can be included.

Gaps remain visible; missing evidence must not be invented.
02

Preparation

What needs to be ready before start

Materials

Shared workspace, accessible sources, and a decision log.

People / roles

On-call expert · service owner · reviewer

Pre-read

Clarify the question, timeframe, data access, roles, and known uncertainties in advance.

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.

03

Core question

The one question this method answers

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

04

Flow

Phases with goal, actions, output and pitfall

A runbook describes a repeatable operational procedure with a trigger, safe steps, decision points, and escalation. It makes prerequisites and limits visible so the next step can be justified.

Trigger, diagnosis, escalation, and recovery

Fictional worked example

Document a repeatable operational procedure with trigger, safe steps, decision points, and escalation.

Trigger

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

Queue age >5 min across three measurements; service: payments-consumer.

Diagnose

List read-only checks with expected results.

Dashboard → consumer health → last change; record timestamps and finding.

Action

Record authorization, escalation contact, and recovery path.

Scale only with approval; if data loss suspected, do not purge, escalate to Incident Commander.

Verify

Record tester, exercise date, owner, and freshness.

Queue age <1 min for 10 minutes; otherwise rollback and escalate. Owner SRE; review Sep 30.

Fictional runbook “Investigate queue backlog”: trigger: queue age >5 min for 3 measurements; check impact and dashboard; inspect consumer health and recent changes; scale only after approval; if data loss is suspected, do not purge and page Incident Commander; success: age <1 min for 10 min.

Being On-Call · Google SRE Workbook

  1. 1

    Trigger

    Define trigger and scope

    Goal

    Is the trigger measurable?

    Inputs for this step

    • Service, alert, trigger, and scope

    Actions

    • Describe symptoms, service, prerequisites, and explicit non-applicability.
    • Is the trigger measurable?

    Output

    Measurable trigger and procedure boundary

    Measurable trigger and procedure boundary

    Quality check

    Is the trigger measurable?

    Pitfall

    Step assumes an unknown state State prerequisites, expected result, and safe recovery.

    Timing: Part of the agreed work block; research may be separate.

  2. 2

    Procedure

    Write safe steps

    Goal

    Can each step be executed with safe context?

    Inputs for this step

    • Access, read-only checks, and expected results

    Actions

    • Order reversible diagnostics before changes; state expected results and stop conditions.
    • Can each step be executed with safe context?

    Output

    Validated safe diagnostic sequence

    Validated safe diagnostic sequence

    Quality check

    Can each step be executed with safe context?

    Pitfall

    Command may irreversibly change data Place read-only diagnostics first and require explicit approval.

    Timing: Part of the agreed work block; research may be separate.

  3. 3

    Escalation

    Define escalation and recovery

    Goal

    Is there a clear stop point?

    Inputs for this step

    • Escalation, approval, rollback, and success criterion

    Actions

    • Name roles, limits, escalation, rollback, and success criterion.
    • Is there a clear stop point?

    Output

    Escalation, rollback, and success criteria

    Escalation, rollback, and success criteria

    Quality check

    Is there a clear stop point?

    Pitfall

    Procedure is stale for current version Maintain version, owner, last exercise, and review date.

    Timing: Part of the agreed work block; research may be separate.

  4. 4

    Maintenance

    Exercise and maintain

    Goal

    Is the procedure current and tested?

    Inputs for this step

    • Exercise outcome, owner, and review date

    Actions

    • Have another person test the steps; version owner, change date, and review date.
    • Is the procedure current and tested?

    Output

    Exercised runbook with review ownership

    Exercised runbook with review ownership

    Quality check

    Is the procedure current and tested?

    Pitfall

    Escalation path is unavailable Define and periodically test a backup contact and path.

    Timing: Part of the agreed work block; research may be separate.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Runbook · Operational ProcedureConnect trigger, checks, commands, verification, and escalation into a reliable operations procedure
RunbookThe visual shows an operational flow from trigger through checks, diagnosis, remediation, verification, and escalation.Make operational steps reproducibleA good runbook clearly separates trigger, diagnosis, intervention, verification, and escalation.checksearchactverifyif uncertain1Triggeralert and scope2Quick checkservice, impact, status3Diagnosislogs, metrics, dashboards4Remediationcommand or rollback5Verificationcriteria met?Command blockcopy-safe, versioned, with preconditionsEscalationowner, threshold, and contactFollow-upupdate the runbook afterevery use
Form

Versioned result with question, evidence, open issues, next action, ownership, and review date.

Versioning / ownership

Record date, scope, sources, and changes. Preserve earlier observations.

Tool alternatives
  • Whiteboard or paper
  • Shared spreadsheet
  • Versioned project space

runbook-checklist.md

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

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

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

runbook-beispiel.md

Concrete filled scenario, fictional example

Fictional worked example

Fictional runbook “Investigate queue backlog”: trigger: queue age >5 min for 3 measurements; check impact and dashboard; inspect consumer health and recent changes; scale only after approval; if data loss is suspected, do not purge and page Incident Commander; success: age <1 min for 10 min.

All names and values are invented for illustration. Unresolved explanations remain questions.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Define trigger and scopeStep assumes an unknown stateView in phase
  2. Write safe stepsCommand may irreversibly change dataView in phase
  3. Define escalation and recoveryProcedure is stale for current versionView in phase
  4. Exercise and maintainEscalation path is unavailableView in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The question or boundary remains ambiguous: narrow it first.
Key data or participants are missing: label the gap and arrange access.
The group mixes observation and explanation: revisit the evidence.
An immediate safety or operational risk appears: stop and use the responsible procedures.

Method after Praxisgemeinschaft. The method emerged as a widespread practice and is not clearly attributed to a single originator or organization. Curated with 1 sources.

Sources: Being On-Call · Google SRE Workbook

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Game Day workspace showing the question, observations, and next decision.
DevOps
Game Day

Rehearses the written procedure under controlled failure conditions.

Incident Command workspace showing the question, observations, and next decision.
DevOps
Incident Command

Serves as the prepared procedure for the next real incident response.

View in playbookLearn from IncidentMove from scattered logs and memories to timeline, learning points, and concrete improvements.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods