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 conditionCommon 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=50Fix readiness, or raise the timeout for slow apps
- Crash/probe/scheduling failure → fix it (see CrashLoopBackOff, readiness probe, FailedScheduling guides) and re-run.
- Genuinely slow startup → raise
--timeoutand/or add a startup probe. - Keep
--atomicso a real failure rolls back instead of leaving a half-applied release.
helm upgrade --install <release> ./chart -n <ns> --atomic --timeout 10mHow to prevent it
- Set
--timeoutto the app’s real worst-case startup and use a startup probe. - Fix crashing/Pending pods so
--waitcan actually succeed. - Use
--atomicso timed-out upgrades roll back cleanly.