# A quiet canary is not evidence of a healthy release

Promotion needs relevant observations as well as a low error rate. Show the request count, workload mix and observation window behind the decision.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Start with the changed behaviour

A release affecting file uploads needs upload observations. Thousands of successful page reads do not exercise the code that changed.

Define the operations and cases that matter before selecting the metric. Include boundaries such as large files or a particular permission role where the change is likely to behave differently.

Keep ordinary service health alongside these checks, but do not let it substitute for them.

## Make the denominator visible

Report failures against the number of relevant attempts. Zero failures from two uploads carries less evidence than zero from a representative workload, even though both show a zero percent error rate.

Avoid presenting a universal sample threshold as sufficient for every release. The consequence, expected failure frequency and diversity of inputs determine what evidence is useful.

For an illustrative canary receiving only ten relevant operations per hour, a five-minute pause cannot establish much about that path. Use a longer observation, a targeted cohort or additional controlled tests rather than automatically promoting when the timer expires.

## Compare with a suitable stable group

Compare candidate and stable results over comparable periods and workload classes. A candidate serving internal users may have a different data distribution from the public stable traffic.

Watch latency distributions and task completion, not only average response time. A small group of slow uploads can disappear inside a mostly fast dataset.

Separate failures shared by both versions from candidate-specific regressions while still considering the overall service state. A broad dependency outage may make the release decision inconclusive rather than proving the candidate is safe.

## Define missing and delayed data

Specify what happens when telemetry is unavailable, late or empty. The analysis should hold or request review according to policy, not silently interpret absence as success.

Verify that metric labels and time windows select the actual candidate traffic. Stale release identifiers can make a query inspect yesterday's healthy deployment.

Record the evidence behind promotion so the decision can be reviewed later. A useful release record shows what was exercised, how much was observed and which limitations remained. A green status without those details can overstate confidence.

## Sources

- [Argo Rollouts: analysis](https://argo-rollouts.readthedocs.io/en/stable/features/analysis/)