Helm "timed out waiting for the condition" - Fix --wait Timeouts

With --wait/--atomic, Helm blocks until the release’s resources report Ready. This error means they did not become Ready before the timeout - usually crashing or unschedulable pods, sometimes a genuinely slow-but-healthy rollout that passes on retry.

What this error means

helm install/upgrade --wait fails with Error: ... timed out waiting for the condition (with --atomic, it then rolls back). The chart rendered and applied fine; readiness is what stalled.

Error: UPGRADE FAILED: timed out waiting for the condition

Common causes

Pods never become Ready

New pods CrashLoopBackOff, fail their readiness probe, or stay Pending (no capacity/unbound PVC), so the Deployment never reaches its Ready replica count within the timeout.

Timeout shorter than real startup

A slow-but-healthy app (large image, long migration) legitimately needs more than the default 5-minute --timeout, so the wait expires before it finishes.

How to fix it

Inspect the resources Helm waited on

The timeout is downstream - find which pods are not Ready and why.

kubectl get pods -n <ns> -l app.kubernetes.io/instance=<release>
kubectl describe deploy -n <ns> -l app.kubernetes.io/instance=<release>
kubectl logs -n <ns> -l app.kubernetes.io/instance=<release> --tail=50

Fix readiness, or raise the timeout for slow apps

1. Crash/probe/scheduling failure → fix it (see CrashLoopBackOff, readiness probe, FailedScheduling guides) and re-run.
2. Genuinely slow startup → raise --timeout and/or add a startup probe.
3. Keep --atomic so a real failure rolls back instead of leaving a half-applied release.

helm upgrade --install <release> ./chart -n <ns> --atomic --timeout 10m

How to prevent it

• Set --timeout to the app’s real worst-case startup and use a startup probe.
• Fix crashing/Pending pods so --wait can actually succeed.
• Use --atomic so timed-out upgrades roll back cleanly.

Related guides