| name | rollback-plan |
| description | Explicit revert paths for infrastructure and configuration changes. Use before applying any infrastructure or configuration change, before database migrations, or before any change with production impact. |
| license | MIT |
Rollback Plan
Ensure every infrastructure change has an explicit revert path.
When to Use
The pre-change revert path for a config/infra change or migration — written
before you apply, so a bad change can be walked back. Distinct from
backup-recovery, which protects the data itself; rollback-plan reverts the
change. A risky DB migration typically needs both: a backup (data) and a
rollback plan (schema/app).
Procedure
- Capture state: Before applying changes, record the current known-good state (snapshot, config backup, git SHA).
- Define revert commands: Write explicit rollback commands before executing the change.
- Set success criteria: Define what "change succeeded" means (health check, endpoint response, metric threshold).
- Verify or revert: After applying, run success criteria. If failed — execute rollback immediately.
- Time-box: Set a maximum time window for verification. If criteria not met within the window, revert.
Completion
- Rollback commands documented before the change is applied
- Success criteria defined and verifiable
- Post-change verification passed (or rollback executed)
Anti-Patterns
- Applying changes without a revert path — "we'll figure it out" leads to extended outages
- Vague success criteria — "it looks fine" is not verifiable
- Unbounded verification window — set a time limit or you'll wait forever
