What is Canary Deployment?

The new version deploys alongside the current one and receives a small traffic share, often one to five percent. Both versions are monitored on the same metrics: error rate, latency percentiles, and business indicators such as conversion.

If the canary performs comparably, traffic share increases in stages until the new version handles all of it. If metrics degrade, traffic returns to the stable version and the canary is removed. The comparison against a concurrently running baseline is what makes the signal trustworthy, since both versions face the same conditions.

It catches problems that pre-production testing structurally cannot.

• Real conditions: production traffic, data, and dependencies rather than approximations.
• Bounded exposure: a defect affects a small percentage rather than everyone.
• Statistical comparison: two versions under identical conditions isolate the change.
• Progressive confidence: risk decreases at each stage rather than being accepted at once.

Canaries need enough traffic to produce a signal. One percent of a low volume service may be a handful of requests per hour, from which nothing statistically meaningful can be concluded.

They also miss slow failures. Memory leaks, gradual resource exhaustion, and defects triggered by rare inputs may not appear during a canary window, and a canary that passes is evidence of no fast regression rather than proof of correctness.

Canary controls exposure at the deployment level: a percentage of traffic reaches the new build. It is infrastructure managed and applies to everything in the release.

Feature flags control exposure at the code level: a specific behavior is enabled for a chosen set of users, independent of which build is running. Flags are more precise and require the code to be written for them. The two compose well, with canary de risking the deployment itself and flags de risking individual behaviors inside it.