Canary Release definition
A canary release is a deployment strategy that rolls out a new software version to a small percentage of users or servers first, monitors its behavior and gradually increases its share only if error rates, latency and business metrics stay healthy. If problems appear, the rollout stops and traffic returns to the stable version, limiting impact to a few users.
How does a canary release work?
The name comes from the canaries miners once carried to detect dangerous gas: a small, early signal that protects everyone else. In software, a small slice of real production traffic goes to the new version while the rest stays on the current one. The team compares the two groups, and if the canary looks healthy, its share grows step by step until it serves everyone.
- Deploy the new version alongside the stable one.
- Route a small share of traffic, such as 1 or 5 percent, to the canary.
- Compare its metrics with the stable version over a set period.
- Increase traffic in steps, such as 25, 50 and then 100 percent.
- Abort and route all traffic back at the first sign of trouble.
- Keep the old version running until the rollout completes.
What to monitor during a canary
Comparing the canary with the current version at the same time matters more than absolute thresholds, because it cancels out normal daily traffic patterns. Each step should last long enough to collect meaningful data, which for low-traffic services can mean longer pauses or a larger initial percentage. Sticky assignment keeps each user on one version for a consistent experience.
- Error rates, including HTTP 5xx responses and exceptions.
- Latency at high percentiles, such as p95 and p99.
- Resource saturation: CPU, memory and connection pools.
- Business metrics such as sign-ups, add-to-cart or payment success.
- New error messages in logs that the old version never produced.
- Saturation of downstream dependencies such as databases and third-party APIs.
Automated canary analysis
Manual canaries depend on someone watching dashboards. Automated analysis evaluates metrics at each step and promotes or rolls back without human intervention. Argo Rollouts and Flagger implement this on Kubernetes, using a service mesh such as Istio or Linkerd, or an ingress controller, to split traffic precisely. Spinnaker's Kayenta, developed by Netflix and Google, performs statistical comparison between canary and baseline. Serverless platforms support canaries too, through weighted Lambda aliases or Cloud Run traffic splitting.
Canary releases vs blue-green and feature flags
Blue-green switches all traffic at once with instant rollback, while canaries expose a bad release to only a few users. Feature flags work at a finer level: the code is already deployed, and the flag controls which users see a specific feature. Teams often combine them, using canaries to verify that a new build is stable and feature flags to roll out individual features to chosen user groups.
Canary releases for mobile apps
Mobile apps cannot switch traffic on a server, but the same idea applies. Google Play staged rollouts release an update to a chosen percentage of users, and Apple's phased release spreads an automatic update over seven days. Teams watch crash rates and reviews before widening the rollout, and pause it if problems appear. Nexzem sets up canary analysis for backend services and staged rollouts for mobile apps, with clear metrics that decide each step.