Write a Rollback Plan Prompt Before You Ever Hit Deploy

Nobody writes the rollback plan when things are calm. They write it at 2am, in a thread, while the dashboard is red and someone keeps asking whether the team can just revert. That's the worst possible moment to figure out whether the change is even reversible. A rollback plan prompt moves that thinking to before the deploy, when your judgment is intact and the stakes are hypothetical.

A rollback plan is the part of a deployment that answers: if this goes wrong, how does the team get back? It names what counts as "wrong," lists the steps to reverse the change, and warns where reversing isn't clean. Most teams skip it until they need it.

This job is the risk-rollback-review companion inside the Release Train Coordination Harness pack. The standalone prompt below is the core of it.

Why most rollback advice doesn't help at 2am

Octopus Deploy's rollback strategies guide is solid on concepts: redeploy a previous release, block release progression, automate rollbacks. It's also from 2021 and explicitly notes that "rolling back a database without data loss is extremely difficult." Meegle offers a downloadable rollback-plan template. OneUptime covers how to write effective runbooks.

All real. None of them read your change. A generic template has blank fields you fill in later, which means at 2am, and a concept article tells you rollbacks are hard without telling you whether yours is. The gap is a prompt that takes the specific change you're about to ship and writes the specific plan back.

What you can do with this prompt

• Turn a change description into explicit rollback trigger conditions
• Get the reverse steps in order, not "revert the deploy" hand-waving
• Flag data and schema changes that won't roll back cleanly
• Produce a validation checklist to confirm the system is actually restored
• Define the rollback window: how long you wait before pulling the trigger
• Generate the plan as a runbook you can paste into the deploy ticket

Anatomy of the prompt

Variables
  {{change_description}}  – what's shipping and which systems it touches
  {{deploy_method}}       – how it ships: blue-green, rolling, canary
  {{data_changes}}        – migrations, backfills, schema edits (or "none")
  {{health_signals}}      – the metrics that tell you it's going wrong

Prompt
  Role: SRE writing a rollback plan before deploy.
  Define trigger conditions, ordered reverse steps, data-safety warnings,
  and a validation checklist. Flag anything not cleanly reversible.

Output contract (locked)
  ## Rollback triggers (each: signal, threshold)
  ## Reverse steps (numbered, in order)
  ## Data safety warnings
  ## Validation checklist
  ## Rollback window

The {{data_changes}} variable is the one that earns its keep. Models will write a tidy "revert the migration" step that quietly loses production data. Feeding the schema changes in explicitly forces the warning into the output.

How to run it

1. Describe the change precisely

{{change_description}} should say what's deploying and what it touches, not "the new feature." The plan is only as specific as the change you describe.

2. Declare the data changes honestly

If there's a migration, say so in {{data_changes}}. If you write "none" when there's a backfill, the prompt produces a confident, wrong plan. This is the field that decides whether rollback is even possible.

3. Name the health signals

{{health_signals}} is what turns "if it goes wrong" into measurable triggers. Error rate over 2%, p99 latency past 800ms, whatever your real thresholds are.

4. Read the warnings before the steps

Counterintuitive, but read the data-safety section first. If it says the change isn't cleanly reversible, the reverse steps matter less than the decision to deploy at all.

5. Attach it to the deploy

Paste the runbook into the deploy ticket. A rollback plan that lives in someone's head isn't a plan.

Model behavior worth knowing

Claude is the most reliable at flagging irreversible data changes when you give it the schema diff; it'll write "this migration drops a column and cannot be rolled back without a restore" rather than papering over it. GPT-4o produces cleaner numbered steps but tends to assume reversibility unless {{data_changes}} makes the risk explicit. Gemini sometimes merges triggers and steps into one section, so keep the ## Rollback triggers and ## Reverse steps headings separate in the contract.

A pattern that holds across all three: put the output contract at the end of the prompt, after the pasted change description. On a long change description, a contract stated first gets buried and the model drifts. Models weight the most recent tokens, so the format spec belongs last.

Variables you'll set

Getting started

1. Copy the prompt skeleton into ChatGPT, Claude, or Gemini.
2. Fill {{change_description}} and {{data_changes}} with real detail.
3. Set concrete thresholds in {{health_signals}}.
4. Run it and read the data-safety warnings first.
5. If the change isn't cleanly reversible, decide whether to ship at all.
6. Paste the runbook into the deploy ticket.
7. Reuse the same prompt for the next release.

The rollback plan pairs naturally with the go/no-go call: the deployment go/no-go review prompt won't return GO if rollback readiness scores low, and this prompt is how you raise that score.

When a deploy does go wrong despite the plan, the next move is diagnosis, and the CI failure diagnosis prompt turns the failure logs into a root cause fast. For schema-heavy changes specifically, the Database Migration Safety Harness is the pack that catches the irreversible migration before it ships, which is the rollback you'd rather never need.