---
name: it-service-runbook
description: Creates an operational runbook for an IT service from architecture, support history, dependencies, and operating requirements. Use for managed services, production systems, handover packs, on-call guides, standard operating procedures, and service continuity preparation.
license: Apache-2.0
metadata:
  adlass.categories: "it-security/runbooks, operations/process-documentation"
  adlass.industries: "it-services"
  adlass.tags: "runbook, it-services, operations, recovery, escalation"
  adlass.adaptation: "reference-doc"
  adlass.source: "n8n:IT-01"
  adlass.version: "1"
---

# 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.