Canary Releases Without the Fear
Ship a new version to 5% of real traffic, watch the SLOs, and let the rollout promote itself, or roll itself back, before anyone has to wake up.
A big-bang deploy bets your entire user base on the idea that staging looked enough like production. Progressive delivery makes a much smaller bet: route a sliver of live traffic to the new version, measure it against the same SLOs you already promise, and only widen the door once the numbers earn it.
Canary, blue-green and feature flags are three flavours of the same instinct, never expose 100% of users to a change you have not yet proven in production. The mechanics differ; the goal is identical, shrink the blast radius of being wrong.
Why a percentage beats a prayer
The cheapest place to catch a bad release is before it reaches everyone. A canary at 5% means a regression hits one in twenty requests for a couple of minutes, not every request for however long it takes a human to notice, page someone, and revert. The controller is doing the watching, and it never gets distracted.
Watch a rollout decide for itself
Press Start rollout to step the canary weight up while the controller checks the new version against its error and latency budget at each stage. Then flip inject error budget burn and run it again, when v2 breaches the SLO, the rollout aborts and shifts every request back to v1 on its own.
The signals that actually gate a rollout
A canary is only as good as the questions you ask of it. Weight steps are the easy part; the analysis is where rollouts earn their keep.
- Error rate, compared to the stable version, not to zero. A canary that matches v1 is healthy even if neither is perfect.
- Latency percentiles, p95 and p99, not the average. Tail latency is where users feel a regression first.
- Saturation, CPU, memory and connection pools. A version that is correct but twice as hungry is still a failed release.
- Business signals, checkout success, sign-ups, queue depth. The metrics your users would complain about if they broke.
Compare canary to baseline, never to a fixed threshold. Traffic, time of day and noisy neighbours move your metrics around. Judge v2 against a v1 baseline running at the same moment and you cut false alarms dramatically.
Rollback is the feature, not the failure
The whole point of progressive delivery is that abandoning a release is cheap, automatic and uneventful. If rolling back means a meeting, a redeploy and a held breath, you will promote bad versions just to avoid the pain, exactly the wrong incentive.
# Argo Rollouts: an analysis-gated canary
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 2m }
- analysis: { templates: [{ templateName: slo-check }] }
- setWeight: 25
- pause: { duration: 5m }
- setWeight: 50
- setWeight: 100
# breach the SLO at any step -> automatic abort + rollbackTakeaways
- Expose new versions to a percentage of real traffic, never the whole fleet at once.
- Gate each weight step on error rate, tail latency and saturation versus a live baseline.
- Make rollback automatic and boring so nobody is tempted to skip it.
- Keep one immutable artifact, promote it by weight, not by rebuilding per environment.
Want releases that promote themselves?
We wire Argo Rollouts or Flagger to your SLOs so every deploy is a gated canary with one-click, or zero-click, rollback.
Set up progressive delivery