UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress
Routes helm release-lock errors. Use when helm reports another operation (install/upgrade/rollback) is in progress. Not for chart render failures or RBAC errors.
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 progressWhat to do
- Confirm the stuck state:
helm status [release] -n [namespace]Expected: STATUS shows pending-upgrade or pending-install.
- Find the last good revision:
helm history [release] -n [namespace]Expected: Revision list; note the highest DEPLOYED revision number.
- Roll back to it:
helm rollback [release] [revision] -n [namespace] Expected: Prints Rollback was a success!.
- Re-run the upgrade.
Expected: Proceeds instead of the lock error.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.