Operations Operating practice

Runbook

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

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.

Core question

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

Prepare plan Method guide

Start comparison

Give feedbackIs this method useful to you?

Participants: 1-4
Time: 20-60 min

Phases may be revisited; their order supports the work but does not replace domain judgment.

Runbook workspace showing the question, observations, and next decision.

Trigger
Define trigger and scope
Describe symptoms, service, prerequisites, and explicit non-applicability.
Procedure
Write safe steps
Order reversible diagnostics before changes; state expected results and stop conditions.
Escalation
Define escalation and recovery
Name roles, limits, escalation, rollback, and success criterion.
Maintenance
Exercise and maintain
Have another person test the steps; version owner, change date, and review date.

Review the result and open assumptions at the next suitable checkpoint. Record changes, ownership, and new evidence.

A good fit when

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

Ideal for

On-call Tasks
Incident Response
Repetitive Operations

Not good for

Open discovery
New strategic work

Outputs

Working picture
The working picture covers symptoms, the affected service, prerequisites, and explicit cases where the procedure does not apply.
Testable evidence
The evidence description records roles, limits, escalation, rollback, and the success criterion.
Next step
The next-step record contains a second-person test and the owner, change date, and review date for the version.

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

First step

Start with a bounded question, clarify access and participants, and collect available evidence. Document a repeatable operational procedure with trigger, safe steps, decision points, and escalation.

Open the method guide

Good to do first

DevOps

Blameless Postmortem

Supplies the insight from which a new or changed procedure is drafted.

Where to go next?

DevOps

Game Day

Rehearses the written procedure under controlled failure conditions.

DevOps

Incident Command

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

Deep dive

Purpose

For recurring operational tasks or incidents, the method keeps solid action logic ready. It reduces uncertainty when time pressure, role changes, or rare situations demand fast access.

How it works

Knowledge is condensed along concrete situations so intervention, safeguards, and escalation fit together. This makes implicit experience usable for cover, on-call duty, and automation. Regular maintenance keeps the instructions in sync with the actual state of the system.

In detail

A Runbook makes experience actionable when a situation is rare, critical, or recurs under time pressure. Clarity comes from prerequisites, checkable steps, rollback logic, and escalation points. It only stays reliable if it is tested, adjusted after incidents, and maintained as a source of truth.

Facilitation

Write the runbook against real operator questions and actual incidents, not an idealized textbook scenario. The critical test is a cold start by someone who knows the case but doesn't have every detail memorized. Close with a clearly named source of truth and triggers that make maintenance or adjustment mandatory.

The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.

Open method guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics

Operations Reliability Documentation

Sources

Being On-Call · Google SRE Workbooksre.googleMethod reference reviewed to support the scope and workflow of Runbook. Examples and editorial guidance are original and explicitly fictional.

In playbooks

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

Artifact templates

Runbook: WorksheetPrepare Runbook with a clear question, roles, and sources.

markdown

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.