# kubectl rollout undo: Usage, Options & Common CI Errors

> kubectl rollout undo rolls a Deployment back to its previous or a specific revision. Automated rollback on a failed deploy, and the no-rollback-target error.

Source: https://latchkey.dev/learn/command-reference/kubectl-rollout-undo  
Updated: 2026-06-25

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

```Terminal
kubectl rollout undo deploy/web
kubectl rollout undo deploy/web --to-revision=3
kubectl rollout status deploy/web --timeout=120s   # gate the rollback too
```

## Common 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl rollout undo: Usage, Options & Common CI Errors?

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 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt