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

Fix Helm "cannot re-use a name": run helm list -A --all, then use helm upgrade --install, or helm uninstall the failed release. Covers other namespaces.

easy fix·5 min read

By Vishvesh Patel·DevOps Engineer·Updated 21 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Find the release, including failed ones and other namespaces

Plain helm list hides failed and pending releases and only shows the current namespace. The --all flag and --all-namespaces together are what make an apparently missing release appear.

• Use upgrade --install so the command works either way

This installs when the release does not exist and upgrades when it does, which removes the entire class of error from pipelines that may run against a fresh or an existing environment.

• If the release is stuck in a failed first install, remove it

A release whose very first install failed has no successful revision to roll back to, which is what produces "has no deployed releases" on the next upgrade. Uninstalling and installing again is the way out.

Helm stores one release per name per namespace, as a Secret in that namespace. The name is taken, so the install is refused.

The confusion is that helm list hides more than people expect.

Two flags matter:

You can also see the underlying storage directly:

One Secret per revision. That is the entire release history.

--install makes the command install if absent and upgrade if present, so the same command works on a fresh environment and an existing one. Any deployment pipeline should use this rather than helm install, and this error largely disappears.

This is the same situation from the other side. The first install failed, so there is no successful revision. helm upgrade needs a deployed revision to upgrade from, and helm rollback needs one to roll back to. Neither has anything to work with.

One revision, failed. Uninstall and install again:

Nothing is lost, because nothing was ever successfully deployed. Do check for leftover objects first, since a partial install can leave resources behind:

If there is a good revision, prefer it:

helm rollback with no revision number goes to the previous one. Note it creates a new revision that duplicates the old state rather than deleting history, so revision 4 might be a copy of revision 2.

This leaves the release records in place, so the name stays reserved and helm rollback still works. Useful when you want to remove the workload temporarily and retain the ability to restore it.

Without --keep-history, all revision Secrets are deleted and the name becomes free.

An upgrade that was interrupted, commonly a CI job cancelled or a runner that died, leaves the release in pending-upgrade and every subsequent operation refuses to proceed.

Helm 3.13 added a supported way out:

If that is refused, the older approach is to delete the Secret for the stuck revision so the previous one becomes current:

Make sure no operation is genuinely still running first. Deleting the record of an in-flight upgrade leaves cluster state and Helm's view of it inconsistent.

Two releases called api in different namespaces are unrelated. A collision therefore means someone installed into the namespace you are targeting, which on a shared cluster is worth checking before you uninstall anything.

Why does helm list not show the release that is blocking me?

Because helm list shows only deployed releases in the current namespace by default. A release in failed, pending-install or pending-upgrade state is hidden unless you pass --all, and one in a different namespace is hidden unless you pass --all-namespaces. Those two flags together reveal nearly every "the release does not exist but Helm says it does" case. You can also look at the storage directly with kubectl get secret -l owner=helm,name=<release>.

What does "has no deployed releases" mean?

The release exists but has never reached a successful state, because its first install failed. helm upgrade needs a deployed revision to upgrade from and helm rollback needs one to roll back to, so neither has anything to work with. Confirm with helm history, which will show a single failed revision. The way out is helm uninstall followed by a fresh install, which loses nothing since nothing was ever successfully deployed.

Should I use helm install or helm upgrade --install?

helm upgrade --install for anything automated. It installs when the release is absent and upgrades when it is present, so the same command works against a brand new environment and an existing one without the pipeline needing to know which it is facing. Plain helm install fails on the second run, and plain helm upgrade fails on the first, which is why pipelines using either one eventually hit an error that has nothing to do with the change being deployed.

How do I recover a release stuck in pending-upgrade?

That state usually means an upgrade was interrupted, typically a cancelled CI job or a runner that disappeared. From Helm 3.13, helm rollback handles it directly. If that is refused, delete the Secret for the stuck revision, sh.helm.release.v1.<name>.v<N>, so the previous revision becomes current again. Before doing that, make sure no operation is genuinely still in progress, because deleting the record of a live upgrade leaves the cluster and Helm's view of it inconsistent.

Does uninstalling a release delete its data?

It deletes the Kubernetes objects the release created, which includes PersistentVolumeClaims unless the chart marks them with a helm.sh/resource-policy: keep annotation. Whether the underlying volume survives then depends on the StorageClass reclaim policy. Before uninstalling anything stateful, check what the release owns with kubectl get all,pvc -l app.kubernetes.io/instance=<release>, and consider --keep-history if you want to retain the ability to roll back afterwards.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.