Disaster Recovery Runbook Generation Prompt

This prompt is designed for SREs and platform engineers who need to convert static system architecture documentation, dependency maps, and failure mode analyses into actionable, step-by-step recovery runbooks. The primary job-to-be-done is transforming known failure scenarios and documented system topologies into structured procedures that an on-call engineer can follow under pressure. Use it when you have a well-understood failure mode—such as a database failover, a region loss, or a critical service degradation—and a complete, up-to-date map of the system's components and their dependencies. The prompt forces the model to produce decision points, expected durations, rollback gates, and dependency ordering rather than vague prose, making the output directly usable in an incident response context.

The ideal user has access to a system architecture diagram, a dependency graph, and a specific failure scenario description. Required inputs include the failure mode, the affected components, their upstream and downstream dependencies, and any known recovery constraints like RTO and RPO. The prompt is not a real-time incident commander; it is a preparation tool for building a library of pre-computed runbooks. Do not use this prompt when the system architecture is undocumented, when you need real-time incident response guidance, or when the failure mode is novel and unexplored. In those cases, the model will lack the necessary grounding and may produce plausible but incorrect procedures. For high-risk production systems, always have a human SRE review the generated runbook for correctness and completeness before it is added to the incident response library.

Before using this prompt, ensure your architecture documentation is current and your dependency map is accurate. The quality of the generated runbook is directly proportional to the quality of the input context. If your system topology has changed, re-run the prompt with the updated documentation. After generating a runbook, test it in a sandbox or staging environment to validate the steps, timings, and decision points. A runbook that has not been tested is a liability, not an asset.

This prompt template takes system architecture documentation and produces a structured disaster recovery runbook. It is designed for SREs and platform engineers who need to convert architecture diagrams, dependency maps, and infrastructure specs into actionable recovery procedures. The template forces step-by-step sequencing, decision points, expected durations, and rollback gates—not just a narrative summary. Replace each square-bracket placeholder with your actual inputs before sending to the model. The output is structured JSON suitable for ingestion into runbook automation systems or human-readable documentation.

textCopy
You are a senior SRE generating a disaster recovery runbook from system architecture documentation. Your output must be a step-by-step recovery procedure that an on-call engineer can follow under pressure.

## INPUTS
- System Architecture: [SYSTEM_ARCHITECTURE_DOC]
- Dependency Graph: [DEPENDENCY_GRAPH]
- Infrastructure Specs: [INFRASTRUCTURE_SPECS]
- Known Failure Modes: [KNOWN_FAILURE_MODES]
- Recovery Time Objective (RTO): [RTO_MINUTES] minutes
- Recovery Point Objective (RPO): [RPO_MINUTES] minutes
- Runbook Audience: [AUDIENCE_ROLE]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "runbook_metadata": {
    "generated_at": "ISO timestamp",
    "system_name": "string",
    "rto_minutes": number,
    "rpo_minutes": number,
    "total_estimated_recovery_minutes": number,
    "last_reviewed": null
  },
  "pre_recovery_checks": [
    {
      "check_id": "string",
      "description": "string",
      "command_or_query": "string",
      "expected_result": "string",
      "failure_action": "string"
    }
  ],
  "recovery_phases": [
    {
      "phase_number": number,
      "phase_name": "string",
      "objective": "string",
      "estimated_minutes": number,
      "depends_on_phases": [number],
      "steps": [
        {
          "step_number": "string (e.g., '3.2')",
          "action": "string",
          "command_or_operation": "string",
          "expected_output": "string",
          "success_criteria": "string",
          "failure_criteria": "string",
          "on_failure": "string",
          "rollback_action": "string or null",
          "estimated_minutes": number
        }
      ],
      "decision_points": [
        {
          "condition": "string",
          "options": ["string"],
          "recommended_path": "string",
          "escalation_trigger": "string or null"
        }
      ],
      "rollback_gate": {
        "condition": "string",
        "action": "string",
        "estimated_rollback_minutes": number
      }
    }
  ],
  "post_recovery_validation": [
    {
      "validation_id": "string",
      "description": "string",
      "test_command": "string",
      "expected_result": "string",
      "failure_action": "string"
    }
  ],
  "dependencies": [
    {
      "service_name": "string",
      "recovery_phase": number,
      "external_dependency": boolean,
      "contact_or_escalation": "string"
    }
  ],
  "rollback_plan": {
    "trigger_condition": "string",
    "full_rollback_steps": ["string"],
    "estimated_rollback_minutes": number,
    "data_integrity_check": "string"
  }
}

## CONSTRAINTS
- Steps must be ordered by dependency: no step may reference a resource not yet recovered.
- Every step with a state-changing command must include a rollback_action.
- Decision points must have at least two options and a recommended path.
- Estimated durations must sum to a total within [RTO_MINUTES] minutes; flag any phase that exceeds its allocation.
- External dependencies must include an escalation contact or fallback procedure.
- If the architecture documentation is incomplete for any dependency, mark it with "UNVERIFIED" and note the missing information.
- Do not invent recovery procedures for components not described in the inputs.

## EVALUATION CRITERIA
After generating the runbook, self-check against these criteria and include a "self_eval" object in the output:
{
  "self_eval": {
    "missing_dependencies_detected": ["string"],
    "out_of_order_steps_detected": ["string"],
    "steps_without_rollback": ["string"],
    "unverified_components": ["string"],
    "rto_feasibility": "FEASIBLE|AT_RISK|EXCEEDED",
    "overall_confidence": "HIGH|MEDIUM|LOW"
  }
}

## EXAMPLES
[EXAMPLES]

## TOOLS AVAILABLE
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing [SYSTEM_ARCHITECTURE_DOC] with your actual architecture documentation—this can be a design doc, an infrastructure-as-code repo summary, or a structured description of services and their dependencies. The [DEPENDENCY_GRAPH] placeholder should receive a directed graph or list of service-to-service calls, including external APIs and data stores. For [KNOWN_FAILURE_MODES], supply the output of a prior FMEA or incident postmortem analysis; if none exists, set this to an empty array and the model will flag missing information in the self-eval. The [EXAMPLES] placeholder can contain one or two well-structured runbook excerpts that demonstrate your organization's preferred level of detail and command style. If you have tool definitions for infrastructure commands, supply them in [TOOLS] so the model can reference real operations rather than inventing placeholder commands. Set [RISK_LEVEL] to HIGH, MEDIUM, or LOW to adjust the thoroughness of rollback gates and escalation triggers. After generation, always run the output through a validation harness that checks for out-of-order recovery steps, missing rollback actions, and unverified dependencies before the runbook reaches an on-call engineer.

This prompt is not a one-shot chatbot interaction; it is a component in a high-stakes operational pipeline. The generated runbook must be treated as a draft that requires human approval before it can be used in a live incident. The harness should enforce a strict generate → validate → review → approve lifecycle. Because the prompt consumes sensitive system architecture documentation, the harness must also ensure that the input context is sanitized and that the output is stored in an access-controlled runbook repository, not a general-purpose chat log.

Wire the prompt into an application with a clear state machine. First, assemble the [SYSTEM_ARCHITECTURE] context by pulling relevant documents from your internal knowledge base or service catalog. Use a retrieval step (RAG) if the architecture is too large for a single context window, but prefer a curated, pre-assembled document to avoid retrieval gaps. After the model returns the runbook, run a structural validator that checks for the required sections (e.g., Recovery Steps, Decision Points, Rollback Gates) and parses the JSON output. If the JSON is malformed or missing required fields, use a repair prompt or retry with a stricter schema instruction. Log every generation attempt, the input context hash, and the validator result for auditability.

The most critical harness component is the eval step. Before the runbook reaches a human reviewer, run automated checks for out-of-order recovery steps (e.g., restoring a database before its dependent services), missing dependency references, and unrealistic expected durations. You can implement these as deterministic rule-based checks on the parsed output or as a secondary LLM-as-judge call with a focused rubric. Flag any runbook that fails these evals and block it from entering the review queue. For the human review stage, present the generated runbook alongside a diff against the last approved version and highlight the specific eval warnings. Only after an authorized SRE approves the runbook should it be published to the runbook store. Avoid the temptation to auto-approve; a hallucinated recovery step in a disaster scenario can extend an outage from minutes to hours.