A deploy that needs a human watching Grafana is not a deploy strategy, it is a hostage situation. Progressive delivery makes the release measure itself and roll back automatically when the numbers turn bad.
A canary that analyzes itself
Argo Rollouts steps traffic up gradually and runs an AnalysisTemplate at each step. Fail the analysis and it aborts, no pager, no human.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 2m }
- analysis: { templates: [{ templateName: success-rate }] }
- setWeight: 50
- pause: { duration: 5m }
- setWeight: 100Define what healthy means
The analysis is the contract. If success rate drops below 99% across two reads, the rollout fails and reverts to the stable ReplicaSet automatically.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata: { name: success-rate }
spec:
metrics:
- name: success-rate
interval: 60s
count: 2
successCondition: result[0] >= 0.99
failureLimit: 1
provider:
prometheus:
address: http://prometheus:9090
query: |
sum(rate(http_requests_total{app="api",code!~"5.."}[2m]))
/ sum(rate(http_requests_total{app="api"}[2m]))Operating it
Watch and, if needed, promote or abort from the CLI, but the point is you rarely need to:
kubectl argo rollouts get rollout api --watch
kubectl argo rollouts promote api # skip remaining pauses
kubectl argo rollouts abort api # instant revert to stableWhat makes it actually safe
Analysis on real SLIs (success rate, latency p99), not just pods-are-up
Automatic rollback on failed analysis, the default, not an afterthought
Small first step (5-10%) so a bad build hits few users
A
PodDisruptionBudgetso scale-down never kills your last stable pod
If your rollback plan is redeploy-the-old-tag-and-hope, you have a deploy, not a delivery pipeline.
Blue-green gives you an instant switch; canaries give you a measured one. For anything user-facing, measured wins, because the release proves itself before it owns all your traffic.



