# kubectl wait: Command Reference for CI/CD

> Reference for kubectl wait: block on a condition (Ready, Available, complete, delete) with a timeout, the right way to synchronize CI steps, with an example.

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

Block on a real condition instead of polling get in a loop.

kubectl wait blocks until objects meet a condition, then returns, exiting non-zero on timeout. It replaces brittle sleep-and-poll loops in CI. This reference covers the --for forms and a synchronization example.

## Common flags and usage

- --for=condition=Ready: wait until pods report Ready
- --for=condition=Available: wait for a Deployment to be Available
- --for=condition=complete: wait for a Job to finish
- --for=delete: wait until an object is gone (teardown)
- --for=jsonpath='{.status.phase}'=Running: wait on an arbitrary field
- --timeout=120s: cap the wait and exit non-zero on expiry

## Example

```shell
# Wait for a migration Job, then for the app to be Available
kubectl wait --for=condition=complete job/migrate --timeout=300s
kubectl wait --for=condition=Available deploy/web --timeout=120s
kubectl wait --for=condition=Ready pod -l app=web --timeout=120s
```

## In CI

Use wait before any step that assumes a resource is up: before port-forwarding, before running smoke tests, or before deleting a namespace (--for=delete). It exits non-zero on timeout, which fails the step cleanly instead of letting a later command hit a not-yet-ready resource.

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

kubectl wait blocks until objects meet a condition, then returns, exiting non-zero on timeout. It replaces brittle sleep-and-poll loops in CI. This reference covers the --for forms and a synchronization example.

### In CI?

Use wait before any step that assumes a resource is up: before port-forwarding, before running smoke tests, or before deleting a namespace (--for=delete). It exits non-zero on timeout, which fails the step cleanly instead of letting a later command hit a not-yet-ready resource.

---

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