Sending a new release to a small share of traffic is a useful beginning. The harder questions are what to measure, how long to observe, and when to stop. Without those decisions, a staged rollout can simply spread a problem more slowly.
Choose a cohort that can reveal the change
Consider a release that changes report generation. A random group of users who never generate reports will reveal little. Select a controlled cohort that exercises the affected feature, while limiting the business impact of a failure.
Google’s SRE workbook describes canarying as a limited deployment evaluated against a control. Keep the comparison meaningful: differences in customer size, request mix, or region can explain performance changes that have nothing to do with the release.
Agree the gates before deployment
Define the error, latency, and business-completion signals that would stop expansion. Include a minimum observation period and enough relevant activity to draw a useful conclusion. A quiet service may need a longer window and targeted checks rather than an automatic promotion after a few minutes.
Assign someone to own the decision and make the pause mechanism easy to use. If an alert fires, record whether the rollout stopped automatically or depended on a person noticing it. Both can be valid arrangements, but the team should know which it has.
Check what rollback actually reverses
Returning traffic to the old application does not undo emails sent, jobs queued, or incompatible data written by the new version. Rehearse recovery for those effects before rollout. Keep database changes compatible during the observation window, and verify that both versions can process shared work. After promotion, remove temporary routing rules and record what the canary did and did not exercise.
