Progressive delivery
A canary needs a decision, not just a traffic percentage
Sending a few requests to a new release limits initial exposure. It becomes a useful safety mechanism only when evidence determines whether to continue, pause or recover.
In this article
Choose what the first cohort can reveal
A release changes the way an application calculates a delivery estimate. Sending five percent of traffic to it may reveal crashes quickly, but it says little about a defect that affects only a rare delivery region.
Define the behaviour being tested and choose an initial cohort that exercises it. A random percentage and a selected customer or workload group answer different questions.
Keep the cohort's limitations visible. Internal users may have different permissions, data and usage patterns from customers. Their success should not be treated as proof that every affected workflow is safe.
Compare meaningful outcomes
Record release identity with the telemetry needed to compare the new and stable paths. Use task completion, errors and latency, then add a check for the specific behaviour being changed.
For the delivery example, compare estimates against reviewed synthetic cases and inspect whether customers can complete the booking. An HTTP success rate cannot detect a plausible but incorrect date.
- Limited cohortExpose a defined set of requests to the new release
- ObservationCollect versioned technical and business outcomes
- DecisionContinue, hold or abort using explicit conditions
- Next stageExpand only after sufficient relevant evidence
Treat missing evidence as its own state
A quiet canary with no failures may simply have received no meaningful requests. Require enough relevant observations and an appropriate duration before promotion.
If the metrics system fails, decide whether the release pauses or requires manual review. Do not let an empty query result automatically become a passing result.
Tools such as Argo Rollouts provide canary steps and analysis mechanisms, but the service still needs well-chosen conditions. Automation executes the policy the team defines. It cannot decide whether the selected metric actually represents the changed behaviour.
Keep the old release usable
The stable application must remain compatible with data written during the canary if traffic may return to it. A small traffic percentage does not make an incompatible schema change reversible.
Likewise, an email, external payment or published file cannot be undone by routing requests back. Separate the code rollback from recovery of effects already produced.
Keep sufficient stable capacity to accept returned traffic under the intended strategy. A rollback that first needs a long scale-up may not meet the expected recovery time.
End the rollout deliberately
After full promotion, continue observing the behaviours that need longer to emerge, such as scheduled processing or cache expiry. Record the release decision and any remaining limitations.
Remove temporary flags and duplicate paths when their purpose is complete. A controlled rollout should reduce release risk without leaving permanent branches that nobody remembers how to test.
Primary sources
Argo Rollouts: canary deploymentsArgo Rollouts: analysisReferences checked 11 September 2026.