---
name: operations-runbook
description: Converts system descriptions, alerts, procedures, and incident history into an executable operations runbook with diagnostics, decision points, escalation paths, and verification checks. Use for service operations, recurring incidents, on-call handbooks, maintenance procedures, and runbook standardization.
license: Apache-2.0
metadata:
  adlass.categories: "it-security/runbooks, operations/process-documentation"
  adlass.industries: ""
  adlass.tags: "runbook, operations, alerts, diagnostics, escalation, procedures"
  adlass.adaptation: "reference-doc"
  adlass.source: "original"
  adlass.version: "1"
---

# Operations runbook

## Purpose

Create a practical operating guide from system facts and prior operational knowledge. Make normal checks, alert diagnosis, safe actions, escalation, and recovery verification clear enough for a trained operator to follow.

## Scope

One system or service, its dependencies, recurring tasks, alerts, known failure modes, owners, and existing procedures. **Excluded:** executing commands, changing systems, or inventing credentials or contacts.

## Data basis

- System description, architecture, dependencies, and service objectives.
- Alerts, dashboards, incident history, and existing procedures.
- Ownership, escalation, maintenance, and change policies.

## Result

A runbook, alert-to-action map, and escalation-path document with explicit prerequisites, stop conditions, and evidence checks.

## Quality criteria

- Each procedure has a trigger, precondition, action, expected result, and failure path.
- Every alert maps to a diagnostic or an explicit knowledge gap.
- Contacts and ownership are sourced, not inferred.
- Dangerous or irreversible actions are clearly marked.

## Instructions

Write actions in observable terms and preserve command or metric names from the source. Separate diagnosis from remediation. Never include secrets. If a step depends on undocumented system behavior, mark it as an open question. Prefer a safe verification step before any remediation proposal.

The review should make the population, calculation basis, and exception treatment understandable to a second operator. Preserve source identifiers in every working table, and state the effect of missing evidence on the decision. A reviewer must be able to reproduce each material result from the cited rows, clauses, dates, or policy rules. Where two sources disagree, show both values and explain which source was treated as authoritative.

Use the outputs as review workpapers: retain the source locator beside every material value, and keep planned action separate from completed evidence. The final document must identify the consequence of each gap for the relevant operational or control decision.

## Adapt before use

- Add service objectives, existing runbook standards, and escalation policy.
- Define approved terminology, dashboard names, and maintenance procedures.
- Supply current owners, contacts, and prohibited actions.