A failed upgrade left the release in limbo and Helm refuses to continue. The fix is rollback or recovery — never delete and re-create blindly.
CI pipeline cancelled mid-upgrade, or the upgrade failed in a way that left the release history marked in-progress.
Two CD jobs raced; the second one is blocked forever by the first's stale lock.
helm history <release> -n <namespace>helm rollback <release> <good-revision> -n <namespace>helm upgrade <release> ./chart --atomic --timeout 10m--atomic auto-rolls-back on failure, which is the difference between a 2-minute blip and a stuck release at 3 AM. If rollback is impossible because the release is brand new, helm uninstall + reinstall is the last resort — with a stateful chart, snapshot first.
A previous upgrade was interrupted (ctrl-c, CI timeout, crashed runner) and left a lock. Helm's release state lives in secrets per release: the pending state blocks the next operation.
helm rollback <release> or helm history to inspect; for stubborn cases use helm uninstall + reinstall (the release's manifests are usually in git/CI anyway). For Helm 2, helm rollback with a stored state or remove the stale configmap — Helm 3's secret-based state made interrupted upgrades less frequent.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.
One short email when new fixes and production templates drop. No spam, unsubscribe anytime.
Spin up a cloud server in 60 seconds and reproduce this fix yourself — pay by the hour.
Sentry — Free tier: see the exact line of code that broke, before users report it.
We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush