Skip to content
Latchkey

Helm "UPGRADE FAILED: another operation is in progress" in CI

Helm marks a release "pending-upgrade", "pending-install", or "pending-rollback" while an operation runs. If a prior CI job was cancelled or timed out mid-operation, the release stays locked and the next run refuses to proceed.

What this error means

helm upgrade fails with "Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress". The release shows a pending-* status in helm status though nothing is actually running.

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

Common causes

A previous operation was interrupted

A cancelled or timed-out CI job left the release in a pending-* state. Helm stores that status in the release secret and treats it as a live lock.

Two pipelines deploy the same release at once

Concurrent jobs targeting the same release name and namespace race, and the second sees the first one's pending status.

How to fix it

Roll back to the last deployed revision

  1. Inspect history with helm history <release> -n <ns> to find the last deployed revision.
  2. Roll back to it, which clears the pending lock.
  3. Re-run the upgrade.
Terminal
helm history my-app -n prod
helm rollback my-app <last-deployed-revision> -n prod

Delete the stuck pending release secret

If there is no deployed revision to roll back to (a stuck first install), remove the pending release record so the next install starts clean.

Terminal
kubectl get secret -n prod -l owner=helm,name=my-app
kubectl delete secret -n prod sh.helm.release.v1.my-app.v1

How to prevent it

  • Serialize deploys to one release with a concurrency group so jobs never overlap.
  • Give helm upgrade a generous --timeout so it is not cancelled mid-operation.
  • Avoid hard-cancelling deploy jobs; let Helm finish or fail cleanly.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →