🚨 Helm Error Guide: 'another operation is in progress' Stuck Release

Exact Error Message

$ helm upgrade my-app ./chart -n prod
Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

$ helm status my-app -n prod
NAME: my-app
LAST DEPLOYED: Sat Jun 27 13:40:11 2026
NAMESPACE: prod
STATUS: pending-upgrade
REVISION: 7

What the Error Means

Helm refuses to start a new operation on a release while it believes a previous one is still running. Helm tracks each release’s lifecycle in a state field stored in a Kubernetes Secret (or ConfigMap) named like sh.helm.release.v1.<name>.v<revision>. While an install, upgrade, or rollback runs, that state is set to pending-install, pending-upgrade, or pending-rollback. When the operation completes, Helm flips it to deployed (or failed).

If the Helm process was killed mid-operation — a CI timeout, a Ctrl-C, a crashed runner, or a network drop — the state is never updated and stays pending-*. The next Helm command sees a pending state and assumes another operation is genuinely in progress, so it blocks with this error. The release is “stuck.”

Common Causes

• A previous helm upgrade/install was interrupted (CI job timeout, killed pod, lost connection) and never reached deployed or failed.
• Two Helm operations ran concurrently on the same release (e.g. two pipeline jobs), leaving an inconsistent pending state.
• A long-running upgrade with --wait timed out while Helm was waiting for resources to become ready, and the process was terminated before cleanup.
• The Tiller-less Helm 3 client crashed between writing the pending Secret and finishing the apply.
• Manual deletion or editing of release Secrets that left the latest revision in a pending state.

How to Reproduce the Error

# Start an upgrade that waits on a slow/unready resource, then kill it
helm upgrade my-app ./chart -n prod --wait --timeout 10m &
HELM_PID=$!
sleep 3
kill -9 $HELM_PID        # simulate a CI timeout / killed runner

# Next operation now blocks
helm upgrade my-app ./chart -n prod
# Error: another operation (install/upgrade/rollback) is in progress

Diagnostic Commands

# Current release status (look for pending-*)
helm status my-app -n prod
helm list -n prod --all

# Full revision history and which revision is pending
helm history my-app -n prod

# Inspect the Helm release Secrets directly
kubectl get secret -n prod -l owner=helm,name=my-app \
  --sort-by=.metadata.creationTimestamp

# Decode the status field of the latest release Secret (read-only)
kubectl get secret -n prod sh.helm.release.v1.my-app.v7 \
  -o jsonpath='{.metadata.labels.status}{"\n"}'

# Confirm no Helm process is actually still running in CI
ps aux | grep -i '[h]elm upgrade'

Step-by-Step Resolution

1. Confirm no real operation is running. Make sure no CI job or operator is actively applying this release before you intervene. Check helm history and any running pipelines.

2. Identify the pending revision. helm history shows the stuck revision and the last good one:

helm history my-app -n prod

REVISION  STATUS           CHART          DESCRIPTION
6         deployed         my-app-1.4.0   Upgrade complete
7         pending-upgrade  my-app-1.5.0   Preparing upgrade

3. Roll back to the last deployed revision. The cleanest recovery is to roll back to the last good revision, which resets the state to deployed:

helm rollback my-app 6 -n prod
helm status my-app -n prod   # should now read STATUS: deployed

4. If rollback is rejected, remove the stuck pending Secret. When even rollback complains about a pending operation, delete only the pending revision’s Secret (never the last deployed one):

kubectl delete secret -n prod sh.helm.release.v1.my-app.v7

Helm then sees revision 6 (deployed) as the latest and unblocks.

5. Re-run your upgrade. With the release back to deployed, retry the original operation:

helm upgrade my-app ./chart -n prod --atomic --timeout 10m

--atomic makes Helm automatically roll back on failure, preventing future stuck-pending states.

Prevention and Best Practices

• Always use --atomic (and a sensible --timeout) so a failed or timed-out upgrade rolls back cleanly instead of leaving a pending state.
• Serialize Helm operations per release in CI — never let two jobs upgrade the same release concurrently; use a pipeline lock or concurrency group.
• Give --wait operations a timeout that comfortably exceeds real rollout time, so the process is not killed mid-flight.
• Avoid kill -9 on Helm in CI; allow graceful termination so Helm can finalize the release state.
• Keep release history reasonable with --history-max so you can always identify the last deployed revision. See more in Kubernetes & Helm guides.

Related Errors

• UPGRADE FAILED: cannot patch ... resource exists / conflict — a different upgrade failure mode tied to immutable fields.
• Error: release: already exists — an install collided with an existing release name.
• Error: cannot re-use a name that is still in use — a release was uninstalled but not purged.
• has no deployed releases — every revision is failed/pending, so there is nothing to upgrade from.

Frequently Asked Questions

Is it safe to delete the Helm release Secret? Only delete the pending revision’s Secret, and only after confirming no Helm operation is actually running. Never delete the last deployed revision’s Secret — that is your rollback target and source of truth for the live state.

Why did rolling back also fail with the same error? Helm sometimes treats the pending state as blocking even rollback. In that case, delete the single pending-revision Secret to drop the latest revision back to the last deployed one, then rollback or re-upgrade.

How do I prevent this in CI permanently? Add --atomic to all upgrades, set a concurrency lock so only one Helm job per release runs at a time, and ensure your runner does not hard-kill Helm on timeout. These three changes eliminate almost all stuck-pending cases.

Will deleting the pending Secret lose my data or running pods? No. Helm release Secrets are metadata about the release state, not the workloads themselves. Your running pods, Services, and PVCs are untouched; you are only correcting Helm’s bookkeeping.