Canary Release
Also known as: canary deployment, progressive rollout
A canary release routes a small fraction of production traffic to a new version, compares its error and latency metrics against the stable version, and promotes or rolls back based on the result. It bounds the blast radius of a bad change to the canary's share of users.
Last reviewed · Part of the Architecture Glossary
In practice
A canary without automated analysis is just a slow deploy. The parts that make it work:
- A comparison baseline. Compare canary against the stable version running now, not against yesterday's dashboard — traffic mix changes hour to hour.
- Metrics with thresholds. Error rate, p99 latency, and at least one business metric (checkout completion), each with a fail condition.
- Enough traffic and enough time. 1% of traffic for two minutes on a low-volume service is statistically nothing. Size the step from the request rate needed to detect the regression you care about.
- Automatic rollback, because a human watching a dashboard at 2 a.m. is not a control.
A typical schedule: 1% for 10 minutes, 10% for 20, 50% for 20, then 100% — aborting at any step on a threshold breach.
Canaries catch what staging cannot: real traffic shapes, real data skew, real cache states, real third-party behaviour.
When it matters
Any service with enough traffic to make a small percentage statistically meaningful, and any change whose failure mode is not caught by tests.
Common mistake
Canarying a stateless service while shipping the schema migration to everything at once. The database change has no canary; expand-migrate-contract is what protects it, and forgetting that is how a "safe" rollout takes the whole system down.
See also
- Feature FlagA feature flag is a runtime switch that changes behaviour without a deploy, separating release from deployment.
- Blast RadiusBlast radius is the extent of damage a single failure or change can cause — how many users, tenants, regions or services are affected when one component fails.
- Burn RateBurn rate is how fast an error budget is being consumed relative to the rate that would exactly exhaust it over the SLO window.
- SLO (Service Level Objective)An SLO is a target value for an SLI over a window — for example, 99.9% of requests succeed over 28 days.