How Argo Rollouts actually flips traffic

A plain Kubernetes rolling update replaces pods one by one with no traffic control. You can’t say “send 10% of traffic to the new version and watch it.” Argo Rollouts exists specifically to close that gap.

The mechanism

Argo Rollouts doesn’t replace your Deployment resource — it introduces a Rollout custom resource that controls traffic weighting through either an Istio VirtualService or an AWS ALB TargetGroup, depending on your setup. You define steps, and at each pause it queries Prometheus for real metrics before deciding whether to continue.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: payment-success-rate
        - setWeight: 50
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: payment-success-rate
        - setWeight: 100

The AnalysisTemplate is what makes this more than a timer:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: payment-success-rate
spec:
  metrics:
    - name: success-rate
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{
              service="payment-service", status!~"5.."
            }[5m])) /
            sum(rate(http_requests_total{
              service="payment-service"
            }[5m]))
      successCondition: result[0] >= 0.99
      failureLimit: 2

If the success rate drops below 99% during the canary phase, Argo Rollouts sets the canary weight back to zero and fully restores the stable version. No human needs to be awake for that to happen.

Why this matters more for payment services than most

A bug reaching 100% of traffic on a checkout flow is a financial incident, not just an engineering one. Canary deployment means the blast radius of a bad release is 10% of traffic for five minutes, not 100% of traffic for however long it takes someone to notice and roll back manually.

Sync waves handle a different problem: market order

Sync waves and canary rollouts solve different layers of the same concern. A sync wave controls which market gets a deployment first — Singapore syncs in wave 1, and ArgoCD waits for it to report healthy before touching wave 2.

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"   # Singapore — first

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "2"   # Philippines — after Singapore is healthy

If Singapore’s canary fails and rolls back, wave 2 never triggers. Philippines, Kenya, and every market after it are protected automatically, because the sync wave gate never opens.

The combined picture

Sync waves decide which market gets the change. Argo Rollouts decides how traffic shifts within that market. Run them together and a bad deployment is contained twice — once at the traffic-percentage level, once at the market level — before it can reach a majority of real users.

That’s the actual value of progressive delivery. Not that it prevents bad deploys. It guarantees a bad deploy is small, brief, and automatically reversed before a human has to react.