# argocd app wait: Block Until Healthy

> argocd app wait blocks until an Application reaches a target health or sync state. Reference for --health, --sync, --operation, --timeout, and CI timeouts.

Source: https://latchkey.dev/learn/command-reference/argocd-app-wait  
Updated: 2026-06-30

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

```Terminal
argocd app wait guestbook --health --timeout 300
# wait for both synced and healthy
argocd app wait guestbook --sync --health --timeout 600
```

## Options

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

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

### argocd app wait: Block Until Healthy?

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.

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

---

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