How to Set Up Canary Analysis with Automated Rollback

The manual canary deployment approach covered elsewhere on this blog requires a human watching metrics and deciding when to proceed or roll back — Flagger automates that entire decision loop based on metric thresholds you define once.

Step 1: install Flagger

helm repo add flagger https://flagger.app
helm install flagger flagger/flagger -n istio-system --set meshProvider=istio

Flagger works with several service mesh and ingress options (Istio, Linkerd, NGINX Ingress, App Mesh) — this example assumes Istio for traffic splitting.

Step 2: deploy your application normally first

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  # ... standard deployment spec

Flagger takes over managing this Deployment’s rollout process once a Canary resource references it — the Deployment itself doesn’t need special annotations beforehand.

Step 3: define a Canary resource with promotion criteria

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  service:
    port: 80
  analysis:
    interval: 1m
    threshold: 5
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m

stepWeight: 10 shifts 10% more traffic to the canary every interval; the metrics block defines the actual pass/fail criteria — here, a 99% success rate and under 500ms latency, checked every minute.

Step 4: trigger a canary rollout by updating the deployment

kubectl set image deployment/myapp myapp=myapp:v2.0

Flagger detects the change automatically and begins the analysis-driven rollout — no separate command needed to “start” a canary.

Step 5: watch Flagger’s automated progression

kubectl describe canary myapp

This shows the current traffic weight, the metrics being evaluated each interval, and whether the canary is progressing, holding, or has failed.

Step 6: understand what happens on a metrics failure

If request-success-rate or request-duration breaches its threshold for threshold consecutive checks (5, in this example), Flagger automatically rolls back — routing 100% of traffic back to the stable version and scaling down the failed canary, with no human intervention required.

Step 7: understand what happens on success

Once the canary reaches 100% traffic weight without triggering a rollback, Flagger promotes it — the canary version becomes the new stable baseline, and the whole cycle is ready for the next deployment.

Step 8: add a webhook for custom pre/post-rollout checks

analysis:
  webhooks:
    - name: smoke-test
      url: http://flagger-loadtester.test/
      metadata:
        cmd: "curl -sf http://myapp-canary/health"

Webhooks let you run arbitrary checks (smoke tests, load tests) as part of the automated gate, beyond just the built-in metric thresholds.

Why automating the decision, not just the traffic shift, is the actual improvement here

Manually watching dashboards during a canary rollout doesn’t scale past a small number of deployments, and human judgment during an incident is often slower and less consistent than a pre-defined threshold. Flagger’s real contribution isn’t the traffic-splitting mechanism itself (which plain Kubernetes primitives can also achieve) — it’s replacing “a human decides whether this canary is healthy” with a fast, consistent, metrics-driven decision made automatically, every single deployment.