DevOpsil
Helm
85%
Needs Review

Fix Helm 'Another Operation in Progress' Error

Riku TanakaRiku Tanaka3 min read

The Error: "another operation in progress"

You try to upgrade or install a Helm release and get:

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

Helm refuses to do anything with this release. You're stuck.

Root Cause

Helm stores release state as Kubernetes Secrets (or ConfigMaps in older versions). When a Helm operation is interrupted -- by a CI/CD timeout, a killed terminal session, or a crashed Helm process -- the release gets stuck in a pending-install, pending-upgrade, or pending-rollback state. Helm won't proceed because it thinks a previous operation is still running.

Step-by-Step Fix

1. Check the Current Release Status

helm list -n your-namespace --all

Look for releases with status pending-install, pending-upgrade, or pending-rollback:

NAME        NAMESPACE   REVISION   STATUS           CHART
my-app      production  5          pending-upgrade  my-app-1.2.0

2. Check Release History

helm history my-app -n your-namespace
REVISION  STATUS           CHART          DESCRIPTION
3         superseded       my-app-1.0.0   Upgrade complete
4         deployed         my-app-1.1.0   Upgrade complete
5         pending-upgrade  my-app-1.2.0   Preparing upgrade

3. Roll Back to the Last Successful Revision

The safest fix is to roll back to the last deployed revision:

helm rollback my-app 4 -n your-namespace

This sets the release back to revision 4 (deployed status) and creates a new revision 6 with deployed status.

4. If Rollback Also Fails

If rollback fails too, you need to manually patch the release secret:

# Find the stuck release secret
kubectl get secrets -n your-namespace -l "owner=helm,name=my-app" --sort-by=.metadata.creationTimestamp

# The latest secret will have the pending status
# Delete it to remove the stuck state
kubectl delete secret sh.helm.release.v1.my-app.v5 -n your-namespace

After deleting the stuck secret, the previous successful revision becomes the current one:

helm list -n your-namespace
# Should now show status: deployed (revision 4)

5. If It's a Stuck pending-install (First Install)

When the very first install gets stuck, there's no previous revision to roll back to:

# Uninstall the failed release entirely
helm uninstall my-app -n your-namespace

# If uninstall fails, force it
helm uninstall my-app -n your-namespace --no-hooks

# Clean up any leftover resources
kubectl delete all -l app.kubernetes.io/instance=my-app -n your-namespace

# Now install fresh
helm install my-app ./my-chart -n your-namespace -f values.yaml

6. Verify the Fix

helm list -n your-namespace
# STATUS should be "deployed"

helm status my-app -n your-namespace
# Should show all resources and their states

Prevention Tips

  • Set timeouts on Helm operations in CI/CD: helm upgrade --timeout 10m0s. This lets Helm clean up properly instead of being killed mid-operation.
  • Use --wait flag so Helm tracks the deployment status: helm upgrade --install --wait --timeout 5m0s.
  • Use --atomic flag to auto-rollback on failure: helm upgrade --install --atomic --timeout 5m0s. This prevents stuck states entirely.
  • Never kill Helm processes manually. If a deploy is taking too long, let it timeout gracefully.
  • Use helm diff before upgrades to catch issues before they happen: helm diff upgrade my-app ./chart -f values.yaml.
Share:

Was this article helpful?

Riku Tanaka
Riku Tanaka

SRE & Observability Engineer

If it's not measured, it doesn't exist. SLO-driven, metrics-obsessed, and the person who gets paged at 3 AM so you don't have to. Observability isn't optional.

Related Articles

Discussion