helm upgrade with `--wait` flag would still failed deployment with context canceled even `--timeout` set

[Bryson-Tai]

What happened?

Hi team,

We observed that when using helm upgrade --wait --timeout 15m0s flag, the --wait flag would not get the timeout 15 minutes value but using the default 5 minutes flag. And it produce failure below.

NAME: our-service-name
LAST DEPLOYED: Tue Jan  6 14:27:27 2026
NAMESPACE: namespace-name
STATUS: failed
REVISION: 301
DESCRIPTION: Upgrade "our-service-name" failed: context canceled

Please refer to logs below, the time before the context get canceled is =~ 5 minutes:

upgrade.go:447: 2026-01-06 14:59:57.707335024 +0000 UTC m=+5.097713373 [debug] waiting for release "our-service-name" resources (created: 0 updated: 7  deleted: 0)
wait.go:50: 2026-01-06 14:59:57.707343893 +0000 UTC m=+5.097722234 [debug] beginning wait for 7 resources with timeout of 15m0s
ready.go:303: 2026-01-06 14:59:58.044701646 +0000 UTC m=+5.435080000 [debug] Deployment is not ready: namespace/our-service-name . 0 out of 2 expected pods are ready
...REDACTED LOGS...
ready.go:303: 2026-01-06 15:04:49.830540947 +0000 UTC m=+297.220919301 [debug] Deployment is not ready: namespace/our-service-name. 1 out of 2 expected pods are ready

<logs stop generating and context canceled>

The pods are still able to run until running state. After pods is running, we re-run the same pipeline, the status changed from failed to deployed without waiting for deployment.

We don't have such issue while using v3.15.4

What did you expect to happen?

--wait would get --timeout 15m0s and wait until the set time duration before failure.

How can we reproduce it (as minimally and precisely as possible)?

You may try to create an small application that wait at least 6 minutes to startup in kubernetes.

Helm version

Details

version.BuildInfo{Version:"v4.0.4", GitCommit:"8650e1dad9e6ae38b41f60b712af9218a0d8cc11", GitTreeState:"clean", GoVersion:"go1.25.5", KubeClientVersion:"v1.34"}

Kubernetes version

Details

Client Version: v1.35.0
Kustomize Version: v5.7.1
Server Version: v1.34.1

[gjenkins8]

Need to confirm this behavior, seems like a bug if the report is correct

[Mujib-Ahasan]

Hello, I tested this on version.BuildInfo{Version:"v4.0.4", GitCommit:"8650e1dad9e6ae38b41f60b712af9218a0d8cc11", GitTreeState:"clean", GoVersion:"go1.25.5", KubeClientVersion:"v1.34"}
using helm upgrade --wait --timeout 15m0s with a full pod template change that intentionally delayed readiness for ~7 minutes but could not hit the early context canceled. It would be helpful to get confirmation from others about this.

[Bryson-Tai]

Hi @Mujib-Ahasan, thanks for helping out, you have mentioned you changed the readiness probe to 7 minutes, how does the --wait flag behave behind the scene? Would also like to know does it wait for running state pods or readiness state?

[Mujib-Ahasan]

Hey @Bryson-Tai, here is exactly what I am doing: below is the dep.yaml from templates in my local chart

apiVersion: apps/v1
kind: Deployment
metadata:
  name: slow-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: slow-app
  template:
    metadata:
      labels:
        app: slow-app
      annotations:
        version: v5
    spec:
      containers:
        - name: app
          image: busybox
          command:
            - sh
            - -c
            - |
              echo "Starting..."
              sleep 420   # 7 minutes
              echo "Ready"
              sleep 3600
          readinessProbe:
            exec:
              command:
                - sh
                - -c
                - test -f /tmp/ready
          lifecycle:
            postStart:
              exec:
                command:
                  - sh
                  - -c
                  - |
                    sleep 420
                    touch /tmp/ready 

each time I upgrade, I increase the version number. previously I was doing only increasing the replicas and it was waiting for pods to be ready, not just running. This time the pod template change triggers a full rollout, so all pods need to become ready sequentially, and the total time can exceed the timeout (--timeout). This behavior looks expected(not sure). This time I set helm upgrade --wait --timeout 10m0s. Logs below,

level=DEBUG msg="waiting for resource" name=slow-app kind=Deployment expectedStatus=Current actualStatus=InProgress
level=WARN msg="upgrade failed" name=slow-test error="resource not ready, name: slow-app, kind: Deployment, status: InProgress\ncontext deadline exceeded"
Error: UPGRADE FAILED: resource not ready, name: slow-app, kind: Deployment, status: InProgress
context deadline exceeded

But in both the cases timeout is being respected in my case. (I am testing these all in my mac m4 air). My workflow might be wrong. Tagging more people for confirmation @gjenkins8, @TerryHowe.

[Bryson-Tai]

@Mujib-Ahasan thank you for helping on this, looking forward to contribute some bugs found in Helm to make it better✌️

[Mujib-Ahasan]

@Bryson-Tai, yes sure. I'll try my best to help you out!🙂

[Noksa]

Looks like in the initial commentary logs are from helm3 and not from helm4 how it is mentioned in Details section

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.