Rollback Plan

# Rollback Plan — <change name>
**Owner:** <name>  ·  **Approver for rollback:** <name / role>  ·  **Rollout window:** <YYYY-MM-DD HH:MM TZ>

## 1. The change (one paragraph)
<what ships, where, how it's gated, expected impact>

## 2. Trigger conditions — roll back if ANY of these hold
| Signal | Threshold | Window | Where to look |
|---|---|---|---|
| <metric / alert / user report> | <e.g. p99 > 400ms> | <e.g. 10 min sustained> | <dashboard link / logs query> |

Also roll back on any P1/P2 incident opened against <service> during the window.

## 3. The reverse — exact steps, in order
> Rehearse this in a lower environment before the change ships. The first time you run these under load should not be the real rollback.

1. **Announce** — post in `#<channel>` from the template in §7.
2. **Stop the rollout** — <feature-flag off / freeze the pipeline / halt canary>.
   - Command: `<exact command or console path>`
   - Verify: `<how to confirm it stopped, e.g. flag API returns "off", pipeline status = PAUSED>`
3. **Revert the code / config** — <exactly one action>.
   - Command: `<git revert <sha> && …>` or `<kubectl rollout undo deploy/<name>>` or `<terraform apply -target=…>`
   - Verify: <version endpoint, image tag, config checksum>
4. **Data reversal** — <one of>:
   - Reversible in place: run `<script / migration --down>`.
   - Forward-only (data was written under the new schema): <what stays, what gets quarantined, backfill / cleanup ticket to file>.
   - Not reversible: STOP — escalate to the approver; do not proceed without them.
5. **Drain / warm** — <e.g. flush caches, restart consumers, rewarm feature-flag SDKs>.
6. **Verify recovery** — the same signals in §2 must return to baseline within <N minutes>.

## 4. Data safety
- **What new writes look like:** <schema/columns/values>
- **Reversibility:** ✅ reversible in place · ⚠ forward-only (specify what's kept) · 🛑 destructive (never)
- **PII / compliance touched:** <list, or "none">
- **Backups / snapshots to take before rollout:** <what, retention, restore command>

## 5. Verification checklist (post-rollback)
- [ ] Trigger signals in §2 back within normal range for <window>.
- [ ] No new P1/P2 opened in the <N> minutes after the reverse.
- [ ] Downstream consumers (<list>) show green on their SLOs.
- [ ] The feature-flag / migration / config surface reflects the old state (screenshot / checksum captured).

## 6. What we do NOT do on rollback
- Do not delete data written during the rollout — quarantine it (see §4).
- Do not silently mute alerts to "get clean" — that hides the very signals we need for §5.
- Do not roll forward a "quick fix" before deciding rollback — one direction at a time.

## 7. Comms template
> **Subject:** Rolling back <change name> (<yyyy-mm-dd hh:mm TZ>)
> Triggered by <signal + value>. Reversing per plan; expected recovery <N> minutes. Impact so far: <one line>. Owner on the reverse: <name>. Next update in <N> minutes or on recovery.

## 8. Post-rollback follow-ups (file before you close the incident)
- Root cause captured to <postmortem / incident>.
- Ticket to re-attempt (or kill) the change, with what will be different.
- Any data cleanup / backfill scheduled with an owner and date.