Canary Deployment: Rollout Steps and Pass Criteria

A canary deployment sends a new version to a small slice of production traffic, watches it, and only then widens the rollout. The point is blast radius. If the release is broken, the people who find out number in the dozens rather than the thousands, and the rollback is a traffic weight rather than a redeploy.

Where the name comes from

Coal miners carried caged birds underground as an early warning for gas. Martin Fowler described the software version in 2014 as a way to reduce the risk of a new release. You roll it out slowly to a subset of users before serving it to everyone.

The mechanics of a canary deployment are a weighted router and some patience. One percent of requests go to the new build, you wait, you read the numbers, and you either raise the weight or drop it back to zero.

How does a canary deployment differ from blue/green?

Blue/green keeps two complete environments and flips all traffic at once. AWS classes the canary approach as a more risk-averse variant of the same idea, because the cutover happens in phases instead of a single switch.

Strategy	Traffic during rollout	Rollback move	Real cost
Blue/green	100 percent, one flip	Flip back	Two full environments
Rolling	Shifts as instances restart	Roll forward or back instance by instance	Mixed versions, no control over who gets what
Canary	A chosen percentage, raised in steps	Set the weight to zero	A router that can split traffic, plus a verdict

The last column is where teams get stuck. Splitting traffic is a config change. Deciding whether the new slice is healthy is the actual work, and Google Cloud's deployment strategy docs treat that verification step as part of the definition.

What counts as a passing canary?

Pick the criteria before the rollout starts, and write them as numbers. Error rate on the new slice compared against the old one. Latency at p95 rather than the mean. A bake time long enough for a cache to turn over and for a cron job to fire at least once.

Five minutes is usually too short. We prefer a bake window measured against the slowest periodic thing in the system, which for most services means thirty minutes or one full cache lifetime, whichever is longer.

Who grades the canary?

Almost every guide answers "the metrics", and almost every guide then reads those metrics from the build under test. A version that starts, serves 200s to its own health endpoint and reports clean counters can still be broken for real clients, because the failure sits in front of it.

In our testing the most embarrassing example was a rollout that set a wrong cache-control header. Internal counters were perfect. An external check against the canary hostname caught a stale response inside two minutes, and the weight went back to zero before anyone opened a dashboard.

Give the rollout one signal that does not originate inside the new build. Expose the canary on its own hostname or route, then point a check at it for the length of the window.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "canary - checkout",
    "type": "keyword",
    "target": "https://canary.example.com/checkout",
    "intervalSec": 30,
    "regions": ["los-angeles", "london", "sydney"],
    "keyword": "Order summary",
    "expectedStatus": [200]
  }'

A keyword assertion matters more here than anywhere else. A broken front-end build regularly returns a perfectly valid 200 with an empty page inside it, which a status-code check waves through.

Run it from more than one place so a single slow path does not abort a healthy release. Six probe regions are available as of September 2026, with the egress addresses listed on the probe IPs page. Requiring a second region to agree before acting is the same discipline that keeps failover testing honest.

Common mistakes

A slice too small to mean anything. One percent of low traffic is a handful of requests an hour, and a clean result from six requests is not evidence. Size the canary by request count, not by percentage.

No automatic rollback. If the abort criteria live in someone's head, the rollback happens after the escalation rather than before it. Wire the check into the pipeline and let a failed assertion set the weight to zero.

Watching the wrong signals during a canary deployment. Host metrics look fine during most bad releases. Track the symptoms users feel, which is what the four golden signals are for.

Treated properly, a canary deployment is a measurement rather than a ceremony: one slice of traffic, one written pass condition, and an observer that is not the code being judged. Set the check up before the rollout, keep the interval tight, and delete it once the weight reaches 100 percent. A release check is short-lived, so it fits easily inside the 10 monitors the free plan allows as of September 2026, though the 30-second interval above needs a paid tier.