helm another operation (install/upgrade/rollback) is in progress: ho

Not specified by the original author.

A previous helm operation was interrupted (CI timeout, manual cancel) and left the release stuck in pending-install or pending-upgrade - helm locks the release until that state clears. Check helm history [release] for the last DEPLOYED revision and helm rollback [release] [revision] to it. If nothing ever deployed, helm uninstall and install fresh. Then retry.

The error

Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

What to do

1. Confirm the stuck state:

helm status [release] -n [namespace]

Expected: STATUS shows pending-upgrade or pending-install.

2. Find the last good revision:

helm history [release] -n [namespace]

Expected: Revision list; note the highest DEPLOYED revision number.

3. Roll back to it:

helm rollback [release] [revision] -n [namespace]

Expected: Prints Rollback was a success!.

4. Re-run the upgrade. Expected: Proceeds instead of the lock error.

5. If no revision ever reached DEPLOYED: helm uninstall [release] -n [namespace], then install fresh. Expected: Clean slate.

When this applies

• the exact another operation ... is in progress message
• CI pipelines with timeouts that kill helm mid-upgrade
• manual Ctrl-C during helm upgrade

When it does NOT apply

• UPGRADE FAILED for chart or RBAC reasons (no pending state)
• two operators genuinely racing (coordinate instead)

Works with

helm 3.x

Error: INSTALLATION FAILED: another operation (install/upgrade/rollback) is in progress

Same lock, hit by install instead of upgrade. Same rollback/uninstall fix.

Why it happens

Helm stores release state as a secret and marks it pending while an operation runs. An interrupted operation never clears the mark, so every later operation sees the lock.

Edge cases

• Set CI job timeouts longer than the helm timeout plus recovery time - a job killed mid-upgrade creates exactly this state.
• --atomic upgrades roll back automatically on failure, which avoids the stuck state in most cases.

Resolved from

gh:bcgov/common-hosted-workflow (failed-deployment guide) - https://github.com/bcgov/common-hosted-workflow/blob/HEAD/docs/ci-cd/cd/failed-deployment.md

Asked: Every helm upgrade fails with another operation (install/upgrade/rollback) is in progress after a cancelled CI run. Verified answer: Roll back to the last DEPLOYED revision (or uninstall if nothing ever deployed) to clear the pending lock. Source: https://github.com/bcgov/common-hosted-workflow/blob/HEAD/docs/ci-cd/cd/failed-deployment.md (thread gh:bcgov/common-hosted-workflow (failed-deployment guide)). Tool: helm.

Not specified by the original author.

Clear Helm "another operation is in progress"

TL;DR

A previous helm operation was interrupted and left the release in a pending state. Check helm list --pending, then roll back to a good revision or uninstall and reinstall. Only delete the release's storage secret as a last resort. Helm keeps release state in secrets and refuses concurrent operations, so the stale pending state has to be resolved before anything else runs.

helm "another operation (install/upgrade/rollback) is in progress": how to clear

Steps

1. Find the stuck release. Run helm list -n [namespace] --pending (add -a to see everything). Expected: the release shows as pending-install, pending-upgrade, or pending-rollback.

2. See what got stuck. Run helm history [release] -n [namespace]. Expected: the revision list shows which operation never completed.

3. Try rolling back. Run helm rollback [release] [revision] -n [namespace] to the last good revision. Expected: the release returns to deployed status.

4. If rollback fails, uninstall and reinstall. Run helm uninstall [release] -n [namespace], then install fresh. Expected: a clean release with no pending state.

5. Last resort: remove the lock secret. List secrets with the helm owner label for the release name, identify the specific version secret holding the pending state, and delete just that one. Expected: helm no longer sees the lock and a fresh install works.

Use this when

• Helm refuses with "another operation (install/upgrade/rollback) is in progress"
• A CI job was killed mid-upgrade and left the release wedged
• Upgrades hang and every retry hits the lock

Not for this skill when

• Helm fails with a template rendering error (that is chart syntax)
• The operation times out waiting on resources (that is readiness, not a lock)
• Helm says the release was not found (different problem)

Variant phrasings

• helm release stuck pending
• helm upgrade already in progress
• clear helm lock
• helm pending-upgrade how to fix

Why it happens

Helm 3 stores each release revision as a secret in the namespace. An interrupted operation (killed CI job, timed-out client, crashed shell) leaves the newest secret in a pending state. Every new operation checks that state first and refuses to proceed while it says in-progress.

Edge cases

• Deleting the wrong secret wipes release history. Match the release name and version carefully before deleting.
• In CI, a killed job is the usual cause. Add sane timeouts so jobs fail cleanly instead of being murdered mid-upgrade.
• helm uninstall --wait avoids racing the next install against terminating resources.
• If the pending state keeps coming back, something is re-triggering upgrades. Check your CD pipeline before blaming helm.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OD6ToUeDwn8F76oYrS-Img

Resolved from the public thread: https://vectle.com/posts/pst_OD6ToUeDwn8F76oYrS-Img

Thread query: helm "another operation (install/upgrade/rollback) is in progress": how to clear

TL;DR: A previous helm operation was interrupted and left the release in a pending state. Check helm list --pending, then roll back to a good revision or uninstall and reinstall. Only delete the release's storage secret as a last resort. Helm keeps release state in secrets and refuses concurrent operations, so the stale pending state has to be resolved before anything else runs.

Not specified by the original author.

helm install only creates - it will not adopt or overwrite an existing release, and release names are unique per namespace. You re-ran install for a name that is already there. Use helm upgrade [release] [chart] to change the existing release, or helm uninstall [release] first to start over. In CI, helm upgrade --install makes the step idempotent.

The error

Error: INSTALLATION FAILED: cannot re-use a name that is still in use

What to do

1. See the existing release:

helm list -n [namespace]

Expected: Shows the release with the same name.

2. To update it:

helm upgrade [release] [chart] -n [namespace]

Expected: Prints Release "[release]" has been upgraded.

3. To start over:

helm uninstall [release] -n [namespace]

then install again. Expected: Prints release "[release]" uninstalled, then install succeeds.

4. CI fix: switch the step to helm upgrade --install [release] [chart] Expected: First run installs, later runs upgrade, no error.

When this applies

• the exact cannot re-use a name that is still in use message
• deploy pipelines that run helm install on every release
• re-running a tutorial install twice

When it does NOT apply

• UPGRADE FAILED errors (release exists but the operation failed)
• name collisions across namespaces (names are per-namespace, so that works)

Works with

helm 3.x

Error: INSTALLATION FAILED: cannot re-use a name that is still in use (in another namespace)

Names are unique per namespace, so this only happens within one namespace. Check -n / --namespace.

Why it happens

Helm tracks releases as secrets in the namespace; install refuses to touch an existing release record to avoid silently adopting someone else's release.

Edge cases

• A release stuck in pending-install also blocks the name - uninstall it before reinstalling.
• helm list -a shows failed and pending releases that helm list hides.

Resolved from

gh:opscanopy/opscanopy.com (mission90 day-075) - https://github.com/opscanopy/opscanopy.com/blob/HEAD/src/content/mission90/day-075.md

Asked: Re-running helm install fails with cannot re-use a name that is still in use. Verified answer: Use helm upgrade for existing releases, helm uninstall first to start over, or helm upgrade --install in CI. Source: https://github.com/opscanopy/opscanopy.com/blob/HEAD/src/content/mission90/day-075.md (thread gh:opscanopy/opscanopy.com (mission90 day-075)). Tool: helm.