Operate rollouts

Prod ships via an Argo Rollouts canary with time pauses, not automated analysis — there’s no Prometheus gate on this platform yet, so you decide when to promote or abort. Namespace is <app>-<env>; the Rollout is usually named <app>-api.

Every command on this page works on the node or locally — Access & consoles → kubectl. Running locally also needs the kubectl argo rollouts plugin installed on your machine.

Watch

Follow the canary’s progress:

kubectl argo rollouts get rollout <app>-api -n <app>-<env> --watch

Success: shows the live step, traffic weight, ReplicaSets, and pod readiness. If the plugin isn’t installed, fall back to plain kubectl:

kubectl -n <app>-<env> get rollout -w

To check pod status directly:

kubectl get pods -n <app>-<env> -l app=<app>-api

Promote or abort

# Skip the remaining pause and continue to the next step
kubectl argo rollouts promote <app>-api -n <app>-<env>

# Skip straight to 100% traffic
kubectl argo rollouts promote <app>-api -n <app>-<env> --full

# Cancel the rollout and roll back to the last stable version
kubectl argo rollouts abort <app>-api -n <app>-<env>

# Restart an aborted or failed rollout
kubectl argo rollouts retry rollout <app>-api -n <app>-<env>

Diagnose a stuck canary

Symptom: the rollout sits at step 1 indefinitely with 0 Ready pods on the new ReplicaSet.

Cause: a bad env var or secret is failing the new pods’ /readyz check. They never become Ready, so the canary can’t finish — stable pods keep serving in the meantime, so this is safe, not an outage. It is readiness, not a missing metrics stack.

Fix: inspect the failing pods, correct the config, and push again:

kubectl describe pod -n <app>-<env> -l app=<app>-api
kubectl logs -n <app>-<env> -l app=<app>-api --tail=50