Rollback Runbook Generation Prompt

This prompt is designed for SRE and platform engineering teams during the release preparation phase, not during an active incident. Its job is to take a forward deployment plan—including migration scripts, infrastructure-as-code changes, and service update descriptions—and produce a concrete, step-by-step rollback runbook. The ideal user is a senior engineer or release manager who understands the deployment architecture and can provide the necessary technical context. The required inputs are detailed: you must supply the forward deployment steps, any database migration scripts, infrastructure change descriptions (e.g., Terraform diffs, Kubernetes manifest changes), and the target environment. Without these, the prompt cannot produce a reliable runbook.

Use this prompt when you need a structured, pre-approved draft that reduces cognitive load during a high-pressure rollback. It is most effective for complex, multi-service deployments where the rollback order is non-obvious and manual steps could be missed. The output is a draft runbook containing preconditions, ordered rollback steps, verification checks, and time estimates. This draft is not the final word; it requires human review and approval to become the authoritative procedure. The prompt excels at ensuring no forward step is left without a corresponding rollback step, but it cannot replace the judgment of an on-call engineer who understands the live system's state.

Do not use this prompt during an active incident. It is not designed for real-time execution, nor does it make go/no-go decisions or interface with deployment tooling. It will not execute commands or assess the current health of a production system. If you need a prompt to evaluate whether to trigger a rollback based on live metrics, use the Rollback Trigger Evaluation Prompt instead. If you need to decide between a hotfix and a full rollback, use the Hotfix vs Full Rollback Decision Prompt. This prompt's sole focus is generating a static, pre-planned procedure from a known deployment plan. The next step after generating the runbook is to have it peer-reviewed, approved, and stored alongside the deployment plan in your runbook system.

This prompt template is the core of the playbook. It is designed to be copied directly into your AI harness, with each square-bracket placeholder replaced by concrete, structured data from your deployment pipeline. The prompt instructs the model to act as a meticulous SRE, translating a forward deployment plan into a step-by-step rollback procedure. The output is not a generic checklist; it is a specific, ordered runbook with preconditions, verification steps, and time estimates for each action.

textCopy
You are a senior SRE generating a precise, step-by-step rollback runbook for a critical production deployment. Your output must be directly executable by an on-call engineer under pressure. Do not omit any step from the forward plan.

**FORWARD DEPLOYMENT PLAN:**
[DEPLOYMENT_PLAN]

**INFRASTRUCTURE & CONFIGURATION CONTEXT:**
[INFRASTRUCTURE_CONTEXT]

**REQUIRED OUTPUT SCHEMA:**
[OUTPUT_SCHEMA]

**CONSTRAINTS:**
[CONSTRAINTS]

**RISK LEVEL:** [RISK_LEVEL]

Generate the rollback runbook now, following the output schema and constraints exactly.

To adapt this template, you must provide concrete values for each placeholder. [DEPLOYMENT_PLAN] should contain the full, ordered list of forward deployment steps, including database migrations, infrastructure-as-code changes, and service deployments. [INFRASTRUCTURE_CONTEXT] must include relevant details like service dependencies, load balancer targets, and database replication topology. [OUTPUT_SCHEMA] should be a strict JSON schema or a detailed markdown structure definition, specifying fields like step_id, action, precondition, verification_command, and estimated_time_seconds. [CONSTRAINTS] are critical for safety; for example, you might specify: "All database migration rollback steps must include a manual data integrity check before proceeding. Assume a blue/green deployment model." The [RISK_LEVEL] field (e.g., HIGH, MEDIUM) can be used to conditionally add more rigorous verification steps or human approval gates within the prompt's logic. After generating the runbook, always validate the output against the provided schema and ensure every forward step has a corresponding, correctly ordered rollback step.

The rollback runbook generation prompt is designed to be invoked automatically as part of a deployment pipeline, not run manually in a chat interface. The trigger point is immediately after a deployment plan is finalized but before any migration scripts or infrastructure changes are executed. At this stage, the system should assemble the required inputs—the forward deployment plan, migration scripts, infrastructure-as-code diffs, and environment context—and pass them to the prompt. The output is a structured rollback runbook that must be validated for completeness before the deployment proceeds. If the runbook is missing steps that correspond to forward deployment actions, the pipeline should block the deployment and alert the release manager.

Pipeline Integration Pattern: Wire the prompt into a CI/CD stage that runs after plan approval and before execution. Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enforce the output schema with function calling or structured output mode. The application layer should: (1) assemble the [DEPLOYMENT_PLAN], [MIGRATION_SCRIPTS], [INFRASTRUCTURE_CHANGES], and [ENVIRONMENT_CONTEXT] placeholders from the deployment tooling; (2) call the model with the prompt template; (3) validate the output against the expected schema—every forward step must have a corresponding rollback step with preconditions, verification checks, and time estimates; (4) run an automated completeness check that flags any forward action without a matching rollback entry; (5) if completeness is below 100%, retry once with a focused error message injected into the prompt context, then escalate to human review if the retry also fails. Log every generation attempt, the completeness score, and the final runbook for audit purposes.

Validation and Retry Logic: The primary failure mode is an incomplete runbook—the model omits rollback steps for certain forward actions, especially for schema migrations with destructive changes or infrastructure modifications with stateful resources. Implement a post-generation validator that parses the forward deployment plan into a list of discrete actions and cross-references them against the rollback steps. Use exact string matching on resource identifiers (table names, service names, config keys) to detect gaps. If gaps are found, construct a retry prompt that appends the missing actions and a specific instruction: The following forward actions have no corresponding rollback steps: [MISSING_ACTIONS]. Generate rollback steps for each. Set a maximum of two retries before blocking the pipeline. For high-risk deployments involving data migrations or stateful infrastructure, always require a human SRE to approve the runbook before execution proceeds, regardless of automated validation scores.

Model Choice and Tool Integration: Choose a model that reliably follows multi-step procedural instructions and produces structured JSON. Avoid smaller or older models that may drop steps or hallucinate verification checks. If your deployment tooling exposes an API for querying resource dependencies, wire it as a tool the model can call during generation to resolve dependency order for rollback sequencing. For example, if the forward plan deploys Service A before Service B, the rollback must reverse that order, and the model should be able to query the dependency graph rather than guess. Store generated runbooks in your incident management or runbook automation platform (e.g., PagerDuty, RunDeck, or a custom ops tool) with a link back to the deployment that triggered the generation. This ensures the runbook is immediately available to on-call engineers if a rollback becomes necessary, without requiring them to locate the right version or regenerate it under incident pressure.