# What is Canary Release?

A canary release is a progressive deployment pattern where a new version of a service rolls out to a small subset of users first — often 1% or 5% — and expands only if monitoring metrics (error rate, latency, custom KPIs) hold steady. If something goes wrong, the canary cohort is small enough to roll back without widespread impact. The name comes from canaries in coal mines: a low-cost early signal of trouble before it spreads.


## Example

Chrome ships a new version to its Canary channel (the smallest
cohort) days before reaching beta, then the Dev channel, then
Beta, then Stable — each step expands the user base while
monitoring for regressions. A SaaS team might deploy v2.3.0 to
5% of internal users for 24 hours, then 25% of all users, then
100% — using a feature flag service like LaunchDarkly to gate the
rollout and observability tooling to watch error rates per cohort.

## Why it matters

Canary releases catch problems before they affect everyone — a bug
that would have hit 100% of users now hits 5%, which is usually
small enough to roll back without making the news. For
high-availability services (anything with paying customers and an
uptime SLA), canary is the default deployment pattern, not an
optional safety net. The cost is operational complexity: you need
per-cohort routing, per-cohort observability, and a clear rollback
procedure. That investment is the table-stakes price of shipping
to production at scale.

## More context

The mechanics of a canary release vary by deployment topology, but the components are consistent:

**Cohort routing.** Some piece of infrastructure — a load balancer, a service mesh, a feature flag platform, an edge function — decides which users see the canary version vs. the stable version. The decision can be by user ID hash (consistent per-user), by random sample, by geography, by account tier, or any combination.

**Per-cohort observability.** Error rate, latency, and custom KPIs (conversion, signups, time-to-first-action, whatever matters) must be measurable separately for the canary cohort and the stable cohort. Without that, you can't tell whether the new version is causing problems — you just see aggregate metrics that average everything together.

**Automated promotion or rollback.** The progression from 5% → 25% → 100% can be manual (an engineer watches the dashboard and clicks the button) or automated (the rollout pauses or rolls back if a metric crosses a threshold). Manual is fine for low-frequency releases; automated is essential for teams shipping daily or hourly.

**A defined rollback procedure.** "Roll back" can mean reverting the deploy, flipping a feature flag, routing the canary cohort back to stable, or some combination. Whatever it is, it has to be a one-click action that doesn't require thinking — because by the time you're rolling back, the dashboards are red and you don't have time to figure out the procedure.

In changelog terms, canary releases create an interesting question: **when do you announce the release?** Most teams announce on full rollout (100%), not on canary deployment — because the canary may roll back and the announcement would be premature. Some teams announce twice: an internal "v2.3.0 entering canary today" note for engineering, then a customer-facing release notes entry when the rollout completes. The split matches the engineering-flavored vs. customer-flavored split in [release notes](/glossary/release-notes/).

## Related terms

- [Release Train](/glossary/release-train/)
- [Breaking Change](/glossary/breaking-change/)
- [Deprecation Policy](/glossary/deprecation-policy/)



Category: Release Engineering
Last reviewed: 2026-05-28