Skip to content
New Signal-based gating for canary steps is live in v2.14 Read the changelog →
← Blog

Engineering ·

Canary analysis in practice

Most canary configurations answer the wrong question: not whether the new build is broken, but whether it is worse.

Nina Berg Nina Berg Staff Engineer

A canary step is usually configured as a threshold: hold at five percent, and roll back if the error rate goes above one percent. It looks like a safety check. Most of the time it is closer to a coin toss.

Thresholds describe the service, not the change

The problem with an absolute threshold is that it has no opinion about what the service was doing before the promotion started. If the baseline error rate is already 0.9%, a threshold of 1% will trip on ordinary variance and roll back a perfectly good build. If the baseline is 0.02%, a change that makes the service fifty times worse still passes comfortably.

Either way the gate is answering “is this service unhealthy?” when the question you actually care about is “is this version worse than the one it is replacing?”

Compare the two populations

Canary analysis works when the canary is measured against the control running beside it, on the same traffic, in the same window. That is the whole idea: two populations, same conditions, one difference.

Three things follow from it.

Measure the control at the same time. Comparing this afternoon’s canary against this morning’s baseline imports every difference between morning and afternoon traffic into your result.

Give it enough traffic to mean something. At five percent of a low-volume service, a handful of requests decides the promotion. Either raise the canary share until the sample is big enough, or hold it long enough to accumulate one.

Watch latency percentiles, not just errors. The most common regression that survives a canary is not a spike in failures — it is p99 latency quietly doubling while the error rate stays flat.

Dwell time is a real parameter

The instinct is to make canary steps short, because a long step feels like a slow deploy. But a step that is shorter than the time it takes for the regression to appear is not a gate; it is a pause.

Anything driven by cache warming, connection pools, memory pressure or a scheduled job will not show up in ninety seconds. If you know your service takes five minutes to reach steady state after a restart, a four-minute canary tells you nothing you did not already know.

What good looks like

A canary step that is worth having states four things explicitly: which signals it compares, what counts as a meaningful difference in each, how long it holds, and what happens on an inconclusive result — because “not enough data” is a different outcome from “no regression”, and treating them the same is how a bad build gets promoted on a quiet Sunday.

Get started

Put every release behind one gate.

Start with a single environment for free. Add the rest when your team is ready — no migration, no rebuild, no second dashboard.

  • Free for one environment
  • SOC 2 Type II
  • Self-host or managed
  • No card required