Uptime
Canary
Canary is a release sent first to a small slice of traffic so a bad build hurts a few users instead of all of them. If the slice looks healthy, the rollout widens.
How it is measured
Compare canary against baseline over the same minutes: error rate, p95 latency, and a business signal like checkout completion. Use a fixed slice, such as 5 percent, and a minimum sample, say 500 requests, before judging.
Decide thresholds before the deploy. A typical rule is canary 5xx no more than 0.5 percentage points above baseline and p95 within 20 percent. Automate the abort.
Worked example
A Remix shop sends 5 percent of requests to build 3f9a for 20 minutes. Baseline 5xx is 0.2 percent. The canary shows 0.3 percent across 700 requests, but /cart/add returns 500 in 11 of 38 attempts, a 29 percent failure. The site-wide error rate barely moves.
The abort fires on the per-route check. Only about 38 visitors ever hit the bug. Had the metric been site-wide, the canary would have looked fine and shipped.
How it differs
Canary exposes a small share to new code. Blue-green deploy swaps everyone at once between whole stacks. A canary excludes instant total cutover. Blue-green excludes the slow real-traffic comparison unless you bolt one on.
Common errors
A slice too small to produce data. Judging only site-wide error rate. Missing sticky routing, so one user bounces between versions. Skipping the canary for small changes. Having no abort rule.
In practice
If your load balancer supports weights, try 5/95 on the next release and watch one route-level metric for 15 minutes. Without weights, canary by region or by internal staff first. Write the abort number on the deploy checklist.