Canary release
kuh-NAIR-ee reh-LEES
Gradually rolling out a new version to a small subset of users before making it available to everyone.
A canary release sends a new version of your software to a small percentage of users first. If the canary is healthy, you gradually increase the percentage. If it is not, you roll back. The name comes from coal miners who brought canaries into mines. If the canary stopped singing, there was gas. Get out.
This is risk management through gradual exposure. Instead of deploying to 100% of users and hoping for the best, you deploy to 1% and watch. Are error rates higher for canary users? Is latency worse? Are business metrics (conversions, engagement) different? If the canary looks good after an hour, increase to 5%. Then 25%. Then 100%.
Netflix pioneered this approach at scale. Every deployment starts as a canary in one AWS region. Automated systems compare canary metrics against baseline metrics. If the canary is statistically worse on any key metric, the deployment is automatically rolled back. No human intervention needed. This is how Netflix deploys hundreds of times per day without breaking the service for 250 million subscribers.
Examples
A team catches a performance regression with a canary.
The new version deploys to 2% of users. After 30 minutes, the canary dashboard shows p99 latency at 800ms versus the baseline's 200ms. The new code has a missing database index. The canary is rolled back, the index is added, and a new canary deploys. The second canary shows matching latency. Rollout continues to 100%. Only 2% of users experienced the slow performance, and most did not notice.
An automated canary analysis rejects a deploy.
The CI/CD pipeline deploys a canary to 5% of traffic and runs automated analysis for 30 minutes. The system compares error rates, latency percentiles, and CPU usage between canary and baseline using statistical hypothesis testing. The canary shows a 0.3% increase in 500 errors, which is statistically significant. The system automatically rolls back and notifies the team. No human was involved.
A canary tests a major infrastructure change.
The team is upgrading the runtime from Node 18 to Node 20. Instead of upgrading everything at once, they run one instance on Node 20 as a canary alongside 49 instances on Node 18. They monitor for 48 hours. Memory usage is 15% lower on the canary. CPU usage is identical. Error rates are identical. They proceed with confidence to upgrade the remaining 49 instances.
In practice
Read more on the blog
Frequently asked questions
How long should a canary run before full rollout?
Long enough to catch problems at your traffic patterns. For most web applications, 30 minutes to 2 hours at 5-10% traffic is sufficient. If your application has daily or weekly traffic patterns (like B2B SaaS with weekday peaks), you might want to canary through a full cycle. The key metric is statistical confidence: have enough requests flowed through the canary to detect a meaningful difference in error rates?
What percentage of traffic should the canary get?
Start with 1-2% for high-risk changes and 5-10% for routine deployments. The trade-off is detection speed versus blast radius. More traffic means faster statistical significance but more users affected if something is wrong. At 1%, a 10x increase in error rate might take 30 minutes to detect. At 10%, you would see it in 3 minutes. Match the canary percentage to the risk level of the change.
Related terms
A deployment strategy using two identical environments to enable instant cutover and rollback.
Updating instances of an application one at a time (or in batches) so the service stays available.
The process of releasing code to servers where users can access it.
Configuration toggles that control which features are active in production without deploying new code.
Continuously checking system health using metrics, dashboards, and alerts to detect problems.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.