A canary release is a deployment strategy where a new version of software is rolled out to a small subset of users before being promoted to the full user base. The name references the practice of sending canaries into coal mines to detect toxic gas before sending miners in.
100% of traffic → v1.2 canary starts: 5% of traffic → v1.3 (canary) 95% of traffic → v1.2 (stable) if metrics look good after N hours: 50% of traffic → v1.3 50% of traffic → v1.2 eventually: 100% of traffic → v1.3
The traffic split is usually done at the load balancer or via a service mesh. Routing can be random (5% of requests go to the new version) or deterministic (specific user IDs or geographic regions see the new version first).
The purpose is to catch bugs that did not appear in staging, because production traffic is different in volume, data patterns, and user behaviour. By limiting the blast radius to 5% of users, a bad release damages far fewer users than a full cutover. Error rates, latency, and business metrics (conversion, session length) are monitored during the canary period; if they degrade, the canary is rolled back.
Canary releasing requires mature observability: you need metrics fine-grained enough to compare the canary cohort against the stable cohort. Without that, you cannot tell whether the new version is behaving differently.
Compare with Blue-green deployment, which switches all traffic at once with an instant rollback option.