Skip to content
Latchkey

Helm "--wait" "timed out waiting for the condition" - Fix Readiness Hangs in CI

helm install/upgrade --wait blocks until the release’s workloads report Ready (or --timeout elapses). A timeout means Helm applied everything fine, but a Deployment/StatefulSet/Job never reached readiness in time - sometimes a genuinely stuck workload, sometimes just slower than the timeout allows.

What this error means

helm upgrade --install --wait exits non-zero with Error: ... timed out waiting for the condition. The resources exist (helm status shows them), but one or more never became Ready before --timeout.

helm output
Error: UPGRADE FAILED: timed out waiting for the condition
# helm waited for e.g. deployment/api to reach its ready replicas and it did not

Common causes

A workload never became Ready

A crashing pod, a failing readiness probe, an unschedulable workload, or an unbound PVC keeps a resource out of Ready, so --wait times out no matter the budget.

Timeout shorter than real startup

A legitimately slow rollout (large image pull, long migration, heavy boot) exceeds the default 5m --timeout - a transient timing miss that passes with more time or a retry.

How to fix it

Inspect the workloads Helm is waiting on

Helm waits on the release’s resources; check them directly to see slow vs stuck.

Terminal
helm status <release>
kubectl get pods -l app.kubernetes.io/instance=<release>
kubectl describe deploy -l app.kubernetes.io/instance=<release> | sed -n '/Conditions/,/Events/p'

Fix readiness, or raise the timeout for slow releases

  1. If a pod crashes / a probe fails / a PVC is unbound, fix that root cause - more time will not help.
  2. If the release is healthy but slow, raise --timeout and wrap the upgrade in a bounded retry.
  3. Wait on the right thing: ensure probes accurately reflect readiness so --wait is meaningful.
Terminal
helm upgrade --install <release> ./chart --wait --timeout 10m

How to prevent it

  • Set --timeout to the release’s realistic worst-case readiness time.
  • Keep readiness probes accurate so --wait reflects true health.
  • Gate CI on helm --wait so a non-ready release fails the deploy, and retry transient slow starts.

Frequently asked questions

What causes "helm --wait "timed out""?
A crashing pod, a failing readiness probe, an unschedulable workload, or an unbound PVC keeps a resource out of Ready, so --wait times out no matter the budget.
How do I fix helm --wait "timed out"?
Helm waits on the release’s resources; check them directly to see slow vs stuck.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card