Canary Release
Routing a small fraction of production traffic to a new version and promoting only if its metrics hold against the incumbent.
A canary is an experiment with a stopping rule, and the stopping rule is the part teams skip. A deployment that sends 5% of traffic to the new version and then proceeds on a timer is not a canary; it is a slower rollout. The canary earns its name only if a defined metric comparison can halt and reverse it automatically.
What to compare: error rate and latency for the canary population against the baseline population over the same window, plus at least one business signal, because plenty of regressions are perfectly healthy from the infrastructure's point of view and quietly stop customers converting.
The statistics matter more than people expect. At 1% of traffic on a low-volume service you may need hours to detect a doubled error rate with any confidence, and teams routinely promote on samples far too small to say anything. If the volume will not produce a signal in a reasonable window, a canary is theatre and a blue-green with fast rollback is the more honest design.
Watch for population skew too: routing by user hash can hand the canary an unrepresentative slice — all internal users, one region, or a single high-volume tenant.