# kubectl rollout status: Command Reference for CI/CD

> Reference for kubectl rollout status: block until a rollout completes and exit non-zero on failure, the canonical CI deploy gate, with --timeout guidance.

Source: https://latchkey.dev/learn/command-reference/kubectl-rollout-status-command-cli-reference  
Updated: 2026-06-26

The canonical CI gate: wait for a deploy, fail on a bad one.

kubectl rollout status blocks until a rollout finishes or its progress deadline is exceeded, returning non-zero on failure. That exit code is what makes it the ideal deploy gate. This reference covers its flags and how to bound it.

## Common flags and usage

- rollout status deploy/<name>: block until the rollout completes
- --timeout=120s: cap the wait, then exit non-zero
- --watch=false: report current status once and return
- --revision=N: check a specific revision rolled out
- Works on Deployments, StatefulSets, and DaemonSets

## Example

```shell
kubectl set image deploy/web web=web:${IMAGE_TAG}
kubectl rollout status deploy/web --timeout=180s || {
  kubectl rollout undo deploy/web
  exit 1
}
```

## In CI

Place rollout status immediately after any change that triggers a rollout (apply, set image, helm upgrade). It exits non-zero on "exceeded its progress deadline" which correctly fails the pipeline. Always pass --timeout so the step fails fast instead of hanging until the job-level timeout.

## 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 status: Command Reference for CI/CD?

kubectl rollout status blocks until a rollout finishes or its progress deadline is exceeded, returning non-zero on failure. That exit code is what makes it the ideal deploy gate. This reference covers its flags and how to bound it.

### In CI?

Place rollout status immediately after any change that triggers a rollout (apply, set image, helm upgrade). It exits non-zero on "exceeded its progress deadline" which correctly fails the pipeline. Always pass --timeout so the step fails fast instead of hanging until the job-level timeout.

---

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