Helm Release Stuck in pending-upgrade: How to Unstick It Safely
⏱️ 2 min read
Helm marks a release pending-upgrade while an upgrade runs, and clears it when done. If the process died mid-run — CI killed, cluster unreachable, OOM — the flag stays and every new helm upgrade fails with "another operation (upgrade) is in progress".
The safe unstick sequence
1. Confirm nothing is actually running. kubectl get pods -l app.kubernetes.io/instance=<release> and check for pods mid-rollout. Killing a genuinely-live upgrade is how you get half-deployed charts.
2. Check the helm history. helm history <release> -n ns shows the wedged revision as pending-upgrade while the previous one stays deployed. The cluster is almost certainly still running the last good revision — your app is fine, only Helm's bookkeeping is stuck.
3. Roll back to clear the state. helm rollback <release> <last-good-rev> -n ns usually completes instantly (resources already match) and resets the state machine. This is the gentle fix; try it before anything surgical.
4. Only then, the secret. Helm stores release state in a Secret (sh.helm.release.v1...<revision>) in the release namespace. Deleting the pending-revision Secret is the documented escape hatch when rollback refuses; delete only the wedged revision's Secret, never the deployed one, and take a copy first.
5. Re-run the upgrade. With state cleared, the upgrade applies normally.
Preventing the wedge
Most wedges come from CI pipelines with timeouts shorter than slow image pulls. Set pipeline timeouts generously, and always run helm upgrade --wait --timeout with a real budget (default 5m is often too short for big images). If you want a sandbox to practice the Secret surgery without prod anxiety, a managed Kubernetes control plane on DigitalOcean makes it a ten-minute exercise.