Canary release is rolling out a new version to a small subset of users before promoting it to everyone. Start at 5% traffic, monitor metrics for hours, then gradually increase to 50%, 100%.

Staging deployments pass all tests but fail in production because real traffic has different volume, data patterns, and user behaviour. Deploying to 100% of users exposes those bugs to everyone simultaneously.

Send the new version to 5% of users, watch error rates and business metrics, and rollback immediately if something degrades. This limits the blast radius to a small cohort while proving the new version works. The tradeoff is requiring fine-grained observability to compare the canary cohort against stable traffic. Compare with Blue-green deployment, which switches all traffic at once.

The diagram shows a gradual rollout: 5% canary traffic for one hour, expanding to 25%, then 50%, then 100% if metrics stay healthy.

Hour 0:   5% → v2.0 (canary)    95% → v1.0 (stable)
Hour 1:   Monitor error_rate, latency, conversion_rate
If healthy:
Hour 4:  25% → v2.0             75% → v1.0
Hour 6:  50% → v2.0             50% → v1.0
Hour 12: 100% → v2.0 (completed)

If degradation detected:
Rollback: 0% → v2.0  100% → v1.0 (instant)