IT service runbook

Purpose

Make normal operation, diagnosis, recovery, maintenance, and escalation for a service executable from one controlled document.

Scope

Business applications, infrastructure services, managed platforms, and recurring IT operations. Excluded: live system changes, credential handling, and incident execution.

Data basis

• Service description, architecture and dependency documents, incident history, monitoring definitions, maintenance policy, and escalation matrix.
• The fixed records, tables, or folders in the skill scope that hold the relevant history or schema.

Result

A runbook, verification checklist, and escalation matrix covering service ownership, routine work, failure modes, recovery, and evidence.

Quality criteria

• Every procedure names a starting condition, observable result, and stop condition.
• Dependencies and service impact are identified for each recovery path.
• Failure modes are grounded in incident history or marked as assumed.
• Escalation criteria include the evidence required for handoff.
• The runbook contains no secrets or unverified commands.

Instructions

Write procedures for operators who know the service but not its undocumented history. Separate diagnosis from remediation and reversible from high-risk actions. Use exact names from the service inventory. When a step depends on an environment-specific command or threshold, state the placeholder and put it in Adapt before use rather than inventing it. Link every warning to a concrete failure mode.

Adapt before use

Keep the source trail close to every conclusion and preserve the difference between a source fact, a calculated value, an assumption, and a recommendation. Use stable identifiers across the document and sheet so a reviewer can move from a summary statement to the underlying row and source. Prefer a complete, transparent partial result over a confident answer built on missing evidence.

• Add the service inventory, architecture diagram, and ownership model.
• Define environment names, monitoring thresholds, and approved tools.
• Provide the incident severity and escalation policy.
• Add recovery objectives and maintenance windows.