Canary Release

What it means

A canary release exposes a new version of your software to a small, controlled subset of traffic - the canary - before rolling it out to everyone. The name comes from the canary in a coal mine: the small group surfaces problems early, while most users stay on the known-good version. You route perhaps 1 to 5 percent of requests to the new build, monitor error rates, latency, and business metrics, and only widen the audience once the canary proves healthy. If it degrades, you route traffic back and contain the damage to that small slice.

Why it matters

Canary releasing turns a high-stakes all-at-once cutover into a gradual, observable process. Because only a fraction of users ever touch an unproven change, a regression affects far fewer people and is caught while it is still small. It pairs naturally with automated analysis - if the canary’s metrics cross a threshold, the rollout can halt or reverse on its own. This is one of the core techniques of progressive delivery and a major reason teams deploy with confidence multiple times a day.

In practice

Canaries can be run at the infrastructure layer, shifting traffic between deployment groups, or at the application layer using feature flags to target a percentage of users. Flag-based canaries give you fine-grained control and an instant kill switch if things go wrong. LaunchDarkly drives percentage rollouts through its SDKs, while Harness automates canary analysis in the deployment pipeline. Our walkthrough on how to do a canary release covers metric thresholds and rollback triggers.