Skip to content

canary release

A canary release is a deployment strategy that rolls a new version of software out to a small slice of users or servers first, watches how it behaves, and widens the rollout to everyone only once the early signals stay healthy. The same idea is often called a canary deployment.

The name comes from the caged canaries that coal miners once carried underground as a living gas alarm. If the bird stopped singing, the crew knew to get out long before the danger reached them.

The new version starts behind a sliver of real traffic and earns its way to the rest one step at a time:

Left to right flow. Teal "New version", then "Route 5% of traffic", then a yellow "Signals healthy?" diamond. "yes" leads to green "Widen" and "Promote". "no" leads to coral "Shift back to old".
Healthy signals widen the rollout to everyone, bad signals send that traffic back to the old version.
Language: Text 
Releasing web v2.4.0
  09:00    5%   errors 0.2%   p95 240ms   healthy, hold
  09:20   25%   errors 0.2%   p95 250ms   healthy, widen
  09:50   50%   errors 0.3%   p95 255ms   healthy, widen
  10:30  100%   errors 0.2%   p95 250ms   promote, retire v2.3.1

If a step had instead shown errors spiking or latency climbing, the rollout would stop and shift that traffic back to the old version, so only the canary group ever saw the bad build.

How It Shows Up in Practice

A Python developer meets canary releases at the far end of a continuous deployment pipeline, after the build and tests pass and an artifact is ready to ship.

Instead of replacing the running app all at once, the platform routes a small percentage of requests to the new version and leaves the rest on the old one. Kubernetes tools such as Argo Rollouts and Flagger, service meshes such as Istio, and managed services such as AWS CodeDeploy all express this as a traffic weight that climbs on a schedule.

What makes the canary worth the trouble is the watching, not the splitting. The promotion decision leans on observability data, comparing the new version’s error rate and latency against the old one. An automated rollout halts the moment those numbers breach a threshold. Teams that track an error budget often wire the canary straight into it, so a release that burns too much budget aborts itself before anyone has to page a human.

Canary Release vs. Blue-Green Deployment

A canary release and a blue-green deployment both aim to ship a new version without downtime, but they trade risk for speed differently.

Blue-green stands up a second full environment, then flips every user across in one cut, which is fast but exposes everyone the instant something is wrong. A canary leaks traffic over gradually, so a bad build reaches a few users instead of all of them, at the cost of running two versions side by side for longer.

A nearer cousin replaces instances a handful at a time without holding back a measured test group to judge against before promoting. To weigh that simpler progressive option, read rolling deployment.

Continuous Integration and Deployment for Python With GitHub Actions

Tutorial

Continuous Integration and Deployment for Python With GitHub Actions

With most software following agile methodologies, it's essential to have robust DevOps systems in place to manage, maintain, and automate common tasks with a continually changing codebase. By using GitHub Actions, you can automate your workflows efficiently, especially for Python projects.

advanced devops

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback