Why would `helm test` hang for five minutes and then fail with a timeout?

## The wait is the whole command After `helm test` creates the test resources, its entire job is waiting. It watches each test Pod until the Pod reaches a terminal phase - `Succeeded` or `Failed` - and only then does it have a verdict. The `--timeout` flag bounds that wait, and its default is `5m0s`. If the Pod has not terminated by then, Helm stops waiting and the command fails, but note *how* it fails: you get a wait/timeout error, not "test failed". Those are different diagnoses and they point at different bugs. ## Cause one: the test never ends This is the most common and the most self-inflicted. A test Pod must be a command that runs and exits. If someone writes the test container as a server, a `sleep`, a shell that tails a log, or a retry loop with no bound, the Pod stays in `Running` forever. It is not slowly passing - a passing verdict requires termination with exit code 0, and this Pod will never terminate. The five minutes elapse and Helm reports a timeout. The same shape appears more subtly when the test's own client has no deadline. A request that hangs on a connection that is accepted but never answered will sit there indefinitely; the container process is alive, so the Pod is alive. Every test container should carry its own timeout - a `--max-time` on the request, a bounded retry - so that the *test* decides it failed, in a couple of seconds, with a log line explaining why. A test that fails fast and loudly is worth several that eventually time out. ## Cause two: the Pod never starts Helm is waiting for a terminal phase, and a Pod that never leaves `Pending` never reaches one. If the test image cannot be pulled - wrong tag, no pull secret in that namespace - or the Pod cannot be scheduled, the run looks exactly like a hang from Helm's side. Helm reports a timeout; the actual cause is in the Pod's events, not in any log, because no container ever ran to write one. This is why the triage step is to look at the Pod while the command is still blocked. `--logs` is not useful here: it dumps the test Pods' output *after* the run completes, so during a hang it gives you nothing, and on a Pod that never started there is nothing to give. Watching the test Pod's phase and events directly in the release namespace tells you within seconds whether you are looking at a scheduling problem, an image problem, or a test that is genuinely running and stuck. ## Cause three: it is blocked on something that will never be ready A smoke test that connects to the release's Service will block if the Service has no ready endpoints. That can be a real finding - the app is broken and the test is telling you so - but it presents as a hang rather than as a clean failure, and it is easy to misread. It is especially common immediately after an upgrade, when the test starts before the new Pods are ready, and the test's retry loop is unbounded. ## Choosing a timeout deliberately The instinct on a timeout is to raise `--timeout`. That is usually wrong. Five minutes is already generous for a smoke check; if the test needs longer, the test is doing too much or is waiting for readiness that should have been established before the test ran. The more useful move in a pipeline is the opposite: set a short explicit timeout - a minute or two - so a broken deploy fails the stage quickly instead of holding a runner for five minutes to tell you nothing specific. And because the timeout error is not a test failure, treat the two differently in your runbook. A failed test means an assertion inside your test Pod returned non-zero, and its logs contain the reason. A timeout means Helm never got a verdict, and the reason is in the Pod's phase and events. Conflating them sends people hunting through application logs for a defect that is actually an unschedulable Pod.