Skip to content

Clearing a Helm release stuck pending-upgrade / pending-install

Confirms the release really is stuck in a pending-* state with nothing genuinely in flight, then clears it — via helm rollback when a prior successful revision exists, or by removing the stuck release record when there isn't one (a first install that never completed). It does not cover a helm upgrade that is genuinely still running, or Helm 2's separate Tiller-based failure modes.

Helmkubectl
Unverifiedno reproductions yetWhy this confidence?
Revision 1published by DevYou curationrevision history
Run the diagnosisEvidence and compatibility

Symptoms

The diagnostic path

8 steps. Every step is written out below in full — the interactive version simply follows the branches for you.

  1. Step 1 · StartHelm upgrade fails: another operation is in progress

    Helm refuses to start a new operation while its stored release history says one is already in progress — even if that operation was actually killed (a CI job cancelled mid-run, a network drop) and nothing is running any more.

    What happens next

    • passed → step 2, Confirm the release's stored status

  2. Step 2 · TestConfirm the release's stored status

    Check what Helm itself believes the release's status currently is.

    Read-onlysh
    helm status <release-name> -n <namespace>

    Expected result

    NAME: <release-name>
LAST DEPLOYED: Thu Aug 20 14:02:11 2026
NAMESPACE: <namespace>
STATUS: pending-upgrade
REVISION: 4

    What happens next

    • passed → step 3, Is a Helm operation actually still running right now?
    • failed → step 4, This generic fix doesn't apply
    • unknown → step 4, This generic fix doesn't apply

  3. Step 3 · TestIs a Helm operation actually still running right now?

    Check CI history and with teammates before touching anything — running a manual fix concurrently with a real in-flight operation corrupts the release history further.

    Read-onlysh
    # check CI pipeline history for this release, and any Helm hook Jobs still active
kubectl get jobs -n <namespace> -l app.kubernetes.io/managed-by=Helm

    Expected result

    No resources found in <namespace> namespace.

    What happens next

    • passed → step 5, Does helm history show an earlier successful revision?
    • failed → step 6, Wait for the in-flight operation to finish
    • unknown → step 6, Wait for the in-flight operation to finish

  4. Step 4 · EndThis generic fix doesn't apply

    If STATUS isn't one of the pending-* states, this isn't a stuck-operation problem — re-read the actual error text, it may be a genuinely concurrent Helm process or an unrelated failure.

  5. Step 5 · TestDoes helm history show an earlier successful revision?

    Whether a clean prior revision exists determines which recovery path applies.

    Read-onlysh
    helm history <release-name> -n <namespace>

    Expected result

    REVISION  STATUS      DESCRIPTION
3         superseded  Upgrade complete
4         pending-upgrade  Preparing upgrade

    What happens next

    • passed → step 7, Fix: roll back to the last successful revision
    • failed → step 8, Fix: remove the stuck release record for a first install with no prior revision
    • unknown → step 8, Fix: remove the stuck release record for a first install with no prior revision

  6. Step 6 · EndWait for the in-flight operation to finish

    Something is genuinely still running against this release. Wait for it to finish (or fail) before running anything else against it.

  7. Step 7 · FixFix: roll back to the last successful revision

    This is the safe, supported way to clear a stuck pending-* status when a prior good revision exists.

    Changes statesh

    Changes system or service state. Review before running.

    Reverts the release's live Kubernetes resources to match the specified prior revision and records a new 'deployed' revision, which clears the stuck pending-* status. It does not undo anything beyond that revision.

    helm rollback <release-name> <last-good-revision> -n <namespace>

  8. Step 8 · FixFix: remove the stuck release record for a first install with no prior revision

    There's no earlier deployed revision to roll back to — typically a pending-install that never completed. Helm stores each revision's record as a Secret in the release's namespace; deleting the one for the stuck pending revision lets Helm treat the next attempt as a fresh install. This does not touch any application resources already created in the cluster, only Helm's own bookkeeping.

    Destructivesh

    Can delete data or break a running service. This is not reversible.

    Permanently deletes Helm's stored record of that one revision from the release's history (a Kubernetes Secret); Helm will then allow a fresh install/upgrade, but you lose the ability to helm rollback to that specific revision number afterward.

    kubectl get secrets -n <namespace> -l "owner=helm,name=<release-name>"
kubectl delete secret -n <namespace> sh.helm.release.v1.<release-name>.v<pending-revision-number>

Sources

Why this confidence?

What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.