# Operational runbook template with safe stop conditions

Canonical: https://githtml.com/guides/operational-runbook-template
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

A useful runbook guides a responder from a recognizable symptom to a safe next decision. Begin with scope, prerequisites, read-only checks, and escalation. For any intervention, state authority, expected effect, verification, and a stop condition. A document should help someone recognize when they must not continue.

## Describe the symptom before the remedy

Name the alert or user-visible failure that this runbook addresses. Distinguish similar symptoms that require different procedures; a slow queue and a stalled consumer are not interchangeable. Record the environment, responsible team, and last rehearsal date. Google SRE's troubleshooting guidance emphasizes gathering observations and testing hypotheses. Use that principle to avoid a page that immediately tells every responder to restart something. Explain what a healthy observation looks like and where its definition comes from, rather than inventing a universal threshold.

## Create an observation and decision sequence

Here is an illustrative sequence for delayed exports. First compare the oldest pending job with the team's documented processing objective. Next check whether new jobs are still completing. Then inspect the latest worker deployment and dependency status. If completion continues, collect evidence and contact the export owner; if completion has stopped, follow the separately authorized incident procedure. Record the actual observation beside each step. Never insert real credentials or customer payloads into the runbook. Screenshots should identify the measurement window and omit sensitive fields.

1. Prerequisites: correct environment, approved access, and a named escalation contact.
2. Stop: evidence points outside this service or the stated diagnosis does not fit.
3. Handoff: include timestamps, observations, attempted actions, and remaining uncertainty.

## Make intervention boundaries unmistakable

Place potentially disruptive operations in a separate section with explicit approval requirements. Do not imply that reading the page authorizes production changes. For each approved action, document its rollback limits and the observation that would demonstrate recovery. Rehearse the procedure in an appropriate test environment and update the page when a step is ambiguous. Keep a self-contained HTML copy for reading, with essential text visible without scripts. gitHtml can read the committed document; it does not execute the runbook, monitor the service, or provide an incident command channel.

## Sources and further reading

- [Google SRE: Effective Troubleshooting](https://sre.google/sre-book/effective-troubleshooting/)
- [Google SRE Workbook: On-Call](https://sre.google/workbook/on-call/)

## Related guides

- [Software migration plan template with exit and rollback gates](https://githtml.com/guides/software-migration-plan-template)
- [Release notes template that explains user impact](https://githtml.com/guides/release-notes-template-for-users)
- [Maintainer changelog template for dependable version history](https://githtml.com/guides/maintainer-changelog-template)
- [Incident review template focused on evidence and follow-up](https://githtml.com/guides/incident-review-document-template)

Editorial approach: https://githtml.com/guides/about