argocd app wait: Block Until Healthy
argocd app wait blocks until an Application reaches the requested health and sync status, then exits 0 or times out non-zero.
sync confirms manifests were applied; wait confirms the workloads actually came up. Use wait to make a pipeline fail when a rollout never becomes Healthy.
What it does
argocd app wait polls an Application until it satisfies the conditions you ask for: --health for Healthy status, --sync for Synced, --operation for a running operation to finish. It exits non-zero if --timeout elapses first.
Common usage
argocd app wait guestbook --health --timeout 300
# wait for both synced and healthy
argocd app wait guestbook --sync --health --timeout 600Options
| Flag | What it does |
|---|---|
| --health | Wait until the app is Healthy |
| --sync | Wait until the app is Synced |
| --operation | Wait for an in-flight operation to complete |
| --degraded | Wait until the app is Degraded (for tests) |
| --timeout <sec> | Give up after this many seconds (exit non-zero) |
| --resource <group:kind:name> | Wait on specific resources only |
In CI
Always pass --timeout; the default behavior waits indefinitely and a stuck rollout will hang the runner. Combine --sync --health so the gate covers both that Git was applied and that the workloads are up.
Common errors in CI
"FATA[0300] Timed out (300 seconds) waiting for app to reach a terminal state" means the rollout never became Healthy in the window; inspect with argocd app get. A wait that returns immediately as Healthy on a no-op deploy is expected. "application ... not found" means the app name is wrong or it lives in another namespace (pass --app-namespace).
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