Decide whether to roll back or push through
Weighs reverting against fixing forward when metrics look wrong after a deploy.
| Category | Development › Deploy & operations |
|---|---|
| Tags | ReviewingAnalyzingDeveloper |
Help me decide: roll back, or fix forward. Produce: 1. **Recommendation first — ROLL BACK / FIX FORWARD / WAIT.** One of the three. State it before reasoning. 2. Cost of rolling back: data written under the new version, migrations already run, client versions in the field, work lost. 3. Cost of staying: what degrades, for whom, and whether it compounds with time. 4. **If WAIT: the exact clock time by which the decision is made, and what observation would flip it.** *A wait without a deadline is how a ten-minute incident becomes two hours.* 5. Whether rollback is actually possible — irreversible migrations, consumed messages, sent notifications, changed external state. 6. What to capture before rolling back, since rollback usually destroys the evidence. Rules: - *When rollback is cheap and the symptom is unexplained, recommend rolling back.* Diagnosis is easier without an ongoing incident, and this is the bias people get wrong under pressure. - Fix forward needs a specific known fix, not confidence that one will be found. - If the deploy contained multiple changes, say whether partial rollback is possible.
After pasting, fill in the fields at the bottom (Symptoms · What was deployed · Rollback cost and constraints)
What this prompt does
Rollback decisions slip because "let us watch a bit longer" repeats. This prices both options and forces a clock time on any decision to wait.