Plan a Staged Rollout With Exposure Steps, Watch Metrics, and Kill Criteria

claude-sonnet-5 0 upvotes

Help me plan a staged rollout of a change so that we find problems at small exposure and know in advance when to stop.

I will provide:
- A description of the change and what it touches
- The kind of users or traffic it affects, and rough volumes
- The tools we have for gradual exposure (feature flags, percentage rollouts, regional deploys, canary instances), if any
- What we can and cannot roll back

Produce a plan with these sections:

1. RISK SUMMARY: In 3-5 bullets, what is the realistic worst outcome of this change, and who would be hurt first?
2. EXPOSURE STEPS: A numbered ladder (for example internal users, 1%, 5%, 25%, 100%). For each step give the audience, minimum soak time, and why that duration is long enough to see the problem you are worried about. If the problem only appears on a weekly or monthly cycle, say so and adjust.
3. WATCH METRICS: For each step, 3-6 specific signals to check, split into (a) health signals such as error rate and latency, and (b) correctness signals that would show the change is wrong even when nothing errors. State the comparison baseline.
4. KILL CRITERIA: Concrete numeric thresholds written in advance that mean "roll back now, without debate". Mark which ones are automatic and which need a human decision, and name the role that decides.
5. ROLLBACK PATH: Exactly how to revert at each step, how long that takes, and what cannot be undone (data written in a new format, emails sent, external calls made). Flag any step where rollback is not actually possible.
6. COMMUNICATION: Who needs to be told before, during, and after, and what the message should contain.

If I have not given enough information to set a sensible threshold, say what you would need to know instead of inventing a number. Keep the plan short enough to be pasted into a ticket.