What is Canary Deployment?

#How canary deployment works

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.

#Why canary deployment works

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.

#Limits

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 vs feature flags

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.

#Key takeaways

• A small traffic share runs the new version while a concurrently running baseline provides the comparison.
• It catches problems that pre-production testing structurally cannot, because conditions are real.
• Low traffic services may not generate a statistically meaningful signal at small percentages.
• Slow failures such as memory leaks often survive a canary window undetected.

#Frequently asked

What percentage should a canary start at?

Enough traffic to produce signal within a reasonable window, commonly one to five percent for high volume services and higher for low volume ones.

Which metrics should gate promotion?

Error rate and latency percentiles at minimum, plus at least one business metric. Technical metrics can look fine while conversion drops.

How long should each stage run?

Long enough to cover normal traffic variation, typically at least fifteen to thirty minutes per stage and longer before the final full rollout.