Rollback Readiness Checklist
A pre-flight check that a service can return to a known-good state fast, anchored by an actual timed rollback rehearsal and backward-compatible migrations. Trigger criteria are objective and tied to SLOs, and configuration is reversible independently of code.
When to Use This Checklist
Use this checklist before any deployment where failure has real cost, and especially before changes that touch data schemas or routing. Rollback readiness is the difference between a brief blip and a prolonged outage. The aim is to prove, in advance, that you can return to a known-good state quickly without losing or corrupting data.
How to Use This Checklist
The single most important item is the rehearsal: actually perform a rollback in a pre-production environment and time it. A rollback that has never been executed is a hypothesis, not a plan. While rehearsing, pay close attention to data. Code is easy to revert; data is not. Confirm migrations are backward compatible so the old code can run against the new schema, and that a backup or point-in-time recovery covers the deployment window.
Decouple configuration and feature flags from code so you can disable a problematic feature without redeploying. Write down who may trigger a rollback and tie the decision to objective SLO and error-budget criteria.
What Good Looks Like
The previous artifact is immutable and instantly retrievable, never rebuilt from source under pressure. Migrations follow expand-and-contract so the schema is compatible with both versions during the transition. A runbook spells out the rollback at the command level, and the team has executed it and knows how long it takes. Traffic can be shifted back to the prior version through routing alone, and observability cleanly separates old and new traffic so the impact is measurable. Trigger criteria are objective and pre-agreed, removing hesitation during an incident.
Common Pitfalls
The most common pitfall is a one-way migration: dropping a column or rewriting data so that the old code can no longer function, making rollback impossible. Rebuilding the previous artifact from source during an incident is another trap, since the build may no longer be reproducible. Teams also fail by leaving the rollback decision ambiguous, so no one pulls the trigger until impact is severe. Finally, automated rollback without safe thresholds can flap, repeatedly toggling between versions.
Related Resources
Use blue-green and canary patterns to make rollback a routing change, and feature flags to disable features without a deploy. The expand-and-contract pattern keeps schemas reversible, and error budgets give objective rollback triggers.