kubectl rollout undo: Usage, Options & Common CI Errors
Roll a bad deploy back to a known-good revision in one command.
kubectl rollout undo reverts a controller to its prior revision, or to a revision you name. It is the canonical recovery step a CI pipeline runs when rollout status reports a failed deploy.
What it does
kubectl rollout undo deploy/NAME re-applies the previous revision's pod template, which triggers a fresh rollout back to that state. --to-revision=N targets a specific revision from rollout history; --to-revision=0 (the default) means the immediately previous one.
Common usage
kubectl rollout undo deploy/web
kubectl rollout undo deploy/web --to-revision=3
kubectl rollout status deploy/web --timeout=120s # gate the rollback tooCommon errors in CI
"error: no rollout history found for deployment \"web\"" or a no-op undo happens when only one revision exists - there is nothing to roll back to, common on a brand-new Deployment that failed its very first rollout. In that case there is no good state to return to; fix forward instead. After an undo, always run kubectl rollout status to confirm the rollback itself succeeded - undo can fail for the same reason the original deploy did (bad probe, missing image). Note undo rolls back the pod template, not external state like a database migration the bad release already ran.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes