Canary Deployment

A canary deployment exposes a limited part of real production work to a candidate release before wider rollout. The current release handles the remaining work. The purpose is to gather relevant evidence while limiting the initial impact of a bad change.

Decide what the comparison can reveal

Suppose 5% of 1,000 requests reach a candidate: 50 requests. Even if all succeed technically, they may include no unusual return requests and provide little evidence about that behavior. A traffic percentage is an exposure setting, not a sample-size justification.

Define routing, comparison metrics, observation time, and stop conditions before rollout. Compare similar workloads where possible and inspect important user groups. Long-running sessions may require consistent routing rather than selecting a version independently on each request.

Users receive the candidate's results

Unlike shadow testing, a canary can affect users and trigger real actions. Stop or limit exposure when the agreed failure condition appears, and verify that recovery works with current dependencies.

A canary is not automatically a randomized experiment or proof of causation. Differences in users, timing, and workload can explain observed differences. Its release-safety purpose and any statistical experiment design should be stated separately.

References

• Google SRE: Canarying Releases