Progressive delivery
Reserve capacity for the traffic that returns on abort
A canary changes how load is distributed. Keep the stable path able to absorb recovery traffic and account for cold caches in the candidate.
In this article
Separate traffic weight from resource count
The proportion of requests directed to a candidate is not necessarily the same as its proportion of instances. The routing mechanism and workload distribution determine the actual load.
Measure per-version request rate, concurrency and resource pressure. A small candidate pool can receive a difficult cohort whose requests cost more than average.
Do not infer safety from a low global CPU average while the candidate is saturated.
Check the cold candidate
A new release may start with empty caches and new database connections. Its initial source load can differ from the warmed stable version.
Observe downstream demand as well as candidate response time. A candidate that looks healthy by making more database calls may impose costs on the stable service sharing that database.
Use representative startup tests and limit exposure until the behaviour is understood. Avoid hiding a recurring cold-start defect with an unusually long warm-up that production cannot guarantee.
Preserve abort capacity
If stable capacity is reduced as the rollout expands, determine how quickly it can take traffic back. Keep the recovery delay within the service's requirement.
For an illustrative service receiving 1,000 requests per second, returning 600 candidate requests to a stable pool sized for only 400 can create an immediate overload. Autoscaling may help, but its measured reaction time belongs in the recovery plan.
Check connection pools and downstream quotas too. More application instances do not automatically create more database capacity.
Budget overlap and observation
Running two versions and retaining stable capacity increases temporary cost. Compare that expense with the recovery capability it provides.
Choose observation periods based on relevant evidence, not merely a desire to minimise overlap. A low-traffic service may need a longer window to exercise the changed path.
After promotion, remove unnecessary candidate or stable resources under the chosen rollback policy. Track leftover flags and analysis jobs as well as compute. The rollout should end with a clear supported version and a deliberate recovery posture.
Primary sources
Argo Rollouts: canary deploymentsReferences checked 11 September 2026.