What Is a Canary Deployment?

Last verified on Nov 8, 2026.

A canary deployment releases a new version to a small slice of production traffic first and compares it with the version already running. If it behaves, you expand. If it does not, you pull it back while most users never saw the problem.

Google's workbook gives the reason. Even with a fully automated pipeline, you will not find every release defect until real traffic hits the service, because test environments are not identical to production and tests do not cover every scenario. A release that deploys everywhere at once ships its defects everywhere at once.

How It Works

Google lists three requirements for a canary process:

• A way to deploy the change to a subset of the service's population.
• An evaluation process that decides whether the canary is good or bad.
• That evaluation wired into the release process, so a bad canary stops the rollout.

The traffic split can be done in several ways. Google names backend weights on a load balancer, proxy configuration, and round-robin DNS records. The new version is the canary, and the rest of production is the control.

An Example in Kubernetes

The Kubernetes documentation shows a basic pattern. You run a stable Deployment and a canary Deployment of the same app, distinguished by a track label, and one Service selects both:

# stable: 3 replicas of the old image
labels: { app: guestbook, tier: frontend, track: stable }
# canary: 1 replica of the new image
labels: { app: guestbook, tier: frontend, track: canary }
# service selector omits track, so it spans both
selector: { app: guestbook, tier: frontend }

Changing the replica counts changes the ratio, which is 3

This is different from a Deployment's built-in rolling update. By default a Deployment replaces Pods gradually, keeping at least 75% available and creating at most 125% of the desired count. That limits downtime, but it is not a comparison against a control. Rollback is available through kubectl rollout undo.

Canary Metrics

Choosing what to watch is the hard part. Google's guidance:

• Start from SLIs. Good SLIs map strongly to service health. For a typical web service, HTTP error codes and response latency are the best candidates.
• Keep the list short. Rank candidates by how well they indicate user-perceivable problems and use the top few, perhaps no more than a dozen.
• Avoid overly strict thresholds. They produce false positives that make the canary distrusted.
• Match the window to the canary duration. An hourly metric used to judge a 30-minute canary gives a muddied signal.
• Split the data. Monitoring must break out canary from control, for example by version label.
• Be careful with before/after comparisons. Google calls them risky: they pick the A/B groups by splitting time instead of splitting the population.

Also keep an absolute check, such as your SLO. Canary and control share backends and data stores, so a bad canary can degrade the control too, and a bad signal is not always the canary's fault.

Managed Options on AWS

AWS CodeDeploy offers canary and linear configurations. For Amazon ECS, CodeDeployDefault.ECSCanary10Percent5Minutes shifts 10 percent of traffic first and the remaining 90 percent five minutes later. A linear configuration, such as ECSLinear10PercentEvery1Minutes, adds 10 percent at each interval. For Lambda, a weighted alias splits traffic between two function versions. AWS describes canary as a risk-averse blue/green variant, so read the blue/green deployment entry alongside this one.

Canary Deployment and Regression Detection

A canary only protects you if something is watching the new version. Alert on the metrics you chose, and make sure a regression produces a signal fast enough to act inside the canary window. The page on regression detection after a deploy covers how new failures show up in logs. Slow degradation is a separate case, covered in the guide to latency drift.

Sazabi, an AI-native observability and security platform, takes deployment notifications as webhook events that arrive at the same intake as your logs and become searchable records. Faster detection also shortens the time to repair (MTTR), and an incident severity scale tells you when a bad canary should page someone.