Canary release

Also called: canary deployment, canary testing

Last updated:

A canary release rolls out a change to a small slice of users — the canary — before everyone else. You monitor error rates, latency, and business metrics for that group; if the canary stays healthy you widen exposure, and if it degrades you pull back having affected only a fraction of traffic. The name comes from the canary in a coal mine: an early warning that costs little to lose.

How a canary release works with feature flags

With a flag, the canary is a cohort rather than a separate pool of servers. You serve the new variation to a small share of users through a percentage rollout, watch the metrics for that bucket, and raise the percentage when the signal is clean. Because the new code already shipped behind the flag, promoting or aborting the canary is a configuration change — no redeploy, and a kill switch straight back to the old path if the canary turns sick. The rollout strategies guide covers how the serving is configured.

Canary release vs progressive delivery

A canary release is the first, smallest step of a wider rollout — the initial exposure whose job is early detection. Progressive delivery is the broader practice that contains it: start with a canary, then ramp through larger tiers to 100% as the metrics hold. Put another way, a progressive rollout usually opens with a canary, but the canary is just the first move, not the whole sequence.

Want the full picture? Read the concept guide: Rollout strategies →

Try it in your own app

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call — sign up and ship.