Fix Helm 'another operation (install/upgrade/rollback) is in progress'

Fix Helm 'another operation (install/upgrade/rollback) is in progress'

You run helm upgrade and Helm stops you cold:

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

Every subsequent helm upgrade or helm rollback fails the same way. The release is jammed, and Helm won't touch it until you clear the block. This is one of the most common Helm failures in CI, and once you know what's happening it takes about a minute to fix.

What this error means

Helm records each release as a revision, and each revision has a status. A normal revision ends up deployed, superseded, or failed. But while Helm is actively working, it marks the revision as pending — pending-install, pending-upgrade, or pending-rollback.

Helm sets that pending status before it starts applying changes and flips it to a final status after it finishes. If the helm process dies in between — CI job times out, someone hits Ctrl-C, the pod running Helm gets evicted — the release is left frozen in a pending state. Nothing ever comes back to finish the transaction.

The next time you run Helm against that release, it sees the pending revision, assumes another operation is genuinely running, and refuses to start a second one. There is no live operation; it's a ghost from a crashed run.

Step 1: See the actual error

Find out which release is stuck and in what state. helm history shows every revision and its status:

helm history <release> -n <namespace>

Look for a revision whose STATUS is pending-install, pending-upgrade, or pending-rollback:

REVISION  UPDATED                   STATUS           CHART        APP VERSION
1         Mon Jun 30 10:00:00 2026  deployed         api-1.4.0    1.4.0
2         Mon Jun 30 10:04:00 2026  superseded       api-1.5.0    1.5.0
3         Wed Jul  2 09:12:00 2026  pending-upgrade  api-1.6.0    1.6.0

helm status confirms the same thing and shows when it got stuck:

helm status <release> -n <namespace>

Note two things before you fix anything: the pending revision number (here, 3) and the last revision that was actually deployed (here, 1). Your fix depends on which case you're in.

Cause 1: A stuck upgrade with a prior good revision

This is the common case. The release was running fine on an earlier revision, an upgrade was attempted, and the upgrade process died mid-run. You have a healthy revision to fall back to.

helm history shows an earlier deployed or superseded revision, followed by a pending-upgrade revision at the top.

Fix 1: Roll back to the last deployed revision

Roll back to the last revision that reached deployed. This clears the pending status and returns the release to a known-good state:

# From the history above, revision 1 was the last DEPLOYED one
helm rollback <release> 1 -n <namespace>

Confirm it worked:

helm history <release> -n <namespace>
helm status <release> -n <namespace>

You should now see a fresh deployed revision at the top. From here you can re-run your helm upgrade normally. Pick the last revision that was genuinely healthy — not just the highest-numbered superseded one if that revision was also broken.

Cause 2: Stuck on the very first install

If the release failed on its first install, there is no earlier revision to roll back to. helm history shows a single revision stuck in pending-install:

REVISION  UPDATED                   STATUS           CHART        APP VERSION
1         Wed Jul  2 09:12:00 2026  pending-install  api-1.6.0    1.6.0

helm rollback will fail here — there's no good revision to target.

Fix 2: Uninstall and reinstall

Because nothing ever deployed successfully, the safe move is to remove the release entirely and install it fresh:

helm uninstall <release> -n <namespace>

Then reinstall:

helm install <release> <chart> -n <namespace> --values values.yaml

helm uninstall will clean up whatever resources the failed install did create, so you start from a clean slate. If the reinstall stalls again, fix the underlying reason (a resource that never becomes ready, an invalid image, a webhook blocking creation) before retrying — otherwise you'll land right back in pending-install.

Cause 3: Manually clearing the stuck revision

Sometimes rollback and uninstall both feel too heavy — for example, the cluster resources are actually fine and you only want to erase the bogus pending record so the next upgrade proceeds. Helm stores each revision as a Secret in the release namespace, and you can delete the offending one directly.

Fix 3: Delete the pending revision's Helm secret

List the Helm release secrets:

kubectl get secret -n <namespace> -l owner=helm

You'll see one Secret per revision, named sh.helm.release.v1.<release>.v<N>:

NAME                              TYPE                 DATA   AGE
sh.helm.release.v1.api.v1         helm.sh/release.v1   1      2d
sh.helm.release.v1.api.v2         helm.sh/release.v1   1      2d
sh.helm.release.v1.api.v3         helm.sh/release.v1   1      15m

Delete only the Secret for the pending revision — in this example revision 3:

kubectl delete secret sh.helm.release.v1.api.v3 -n <namespace>

With the pending record gone, Helm falls back to the previous revision as the current state, and your next helm upgrade works.

Be careful here. Delete the wrong Secret and you corrupt Helm's view of the release — Helm may lose track of the deployed revision or its history. Only ever delete the single pending revision's Secret, never a deployed or superseded one. If you're unsure which is which, prefer helm rollback (Fix 1) — it's the safe, supported path. Reach for manual Secret deletion only when rollback genuinely can't help.

Root cause: Helm killed mid-run

Every one of these situations comes from the same thing — the helm process was interrupted between marking a revision pending and finalizing it:

• CI job timeout — the pipeline step running helm upgrade hit its wall-clock limit and was killed.
• Ctrl-C — someone cancelled a slow helm upgrade --wait in a terminal.
• Pod eviction — the pod or runner executing Helm was evicted or OOMKilled mid-apply.
• Network drop — the connection to the cluster died while Helm was waiting on resources.

Helm has no transaction log to replay, so the pending revision just sits there.

Prevention

Make interrupted runs clean up after themselves and stop concurrent runs from racing:

helm upgrade <release> <chart> -n <namespace> \
  --install \
  --atomic \
  --wait \
  --timeout 10m

• --atomic automatically rolls back to the previous revision if the upgrade fails or times out, so you never get left in a pending state.
• --wait --timeout gives slow charts enough time to become ready instead of timing out prematurely. Raise the timeout for charts with heavy init or slow image pulls.
• In your pipeline, add concurrency controls so two deploys of the same release can't run at once (GitHub Actions concurrency:, GitLab resource_group:). Overlapping runs are a classic way to produce a stuck release.

Quick reference

1# 1. Diagnose — find the stuck revision and status
2helm history <release> -n <namespace>
3helm status  <release> -n <namespace>
4
5# 2a. Fix — stuck upgrade, prior good revision exists
6helm rollback <release> <last-deployed-revision> -n <namespace>
7
8# 2b. Fix — stuck on first install, nothing to roll back to
9helm uninstall <release> -n <namespace>
10helm install   <release> <chart> -n <namespace> -f values.yaml
11
12# 2c. Fix — manual: delete only the pending revision's secret
13kubectl get secret -n <namespace> -l owner=helm
14kubectl delete secret sh.helm.release.v1.<release>.v<N> -n <namespace>

Frequently Asked Questions

Why does Helm say an operation is in progress when nothing is running?

Because Helm marks a revision as pending before it applies changes and only clears that status after it finishes. If the process dies in between, the pending status is never cleared. Helm sees the stale pending revision on your next command and assumes a real operation is still active, even though the original process is long gone.

Is it safe to run helm rollback to fix this?

Yes — for a stuck upgrade or rollback where an earlier deployed revision exists, helm rollback is the safe, supported fix. It clears the pending status and returns the release to a known-good revision. It only fails when there's no good revision to target, which is the pending-install case where you should uninstall instead.

How do I know which revision to roll back to?

Run helm history <release> -n <namespace> and pick the most recent revision whose STATUS is deployed (or a superseded revision you know was healthy). Avoid rolling back to a revision that was itself broken. Pass that revision number to helm rollback.

Can I delete the Helm secret to fix a stuck release?

You can, but treat it as a last resort. Delete only the Secret named sh.helm.release.v1.<release>.v<N> that corresponds to the pending revision. Deleting a deployed or superseded Secret corrupts Helm's history and can leave the release untrackable. When rollback works, prefer it over manual secret deletion.

How do I stop this from happening in CI?

Add --atomic --wait --timeout <duration> to your helm upgrade so interrupted runs automatically roll back instead of leaving a pending revision. Then add pipeline concurrency controls so two deploys of the same release never run simultaneously, and raise the timeout for charts that are slow to become ready.

See also

• Building a Multi-Namespace Helm Chart with Environment Overlays
• Helm Best Practices for Production — chart structure, values, and safe release workflows
• Helm Advanced Patterns for Production — hooks, atomic upgrades, and rollback strategy in depth
• Helm vs Kustomize: Choosing a Strategy — when Helm's release model helps and when it gets in the way

Stuck on a broken Helm release in production and not sure it's safe to touch? Talk to us at Coding Protocols — we untangle release state and harden your deploy pipeline so it doesn't happen again.

Official References

• Helm chart template guide — templates, values and the sprig function set
• Helm charts — chart structure, dependencies and hooks