Helm keeps a revision ledger for every release it manages in a Kubernetes namespace. That ledger becomes the recovery point when an upgrade applies the wrong chart, image tag, or values override and the working target is a known earlier revision.

A rollback creates a new release revision that reapplies the selected historical manifest instead of deleting the release and reinstalling it. The release name and namespace must match the application being recovered, and the history table shows the revision number to target before changing the cluster.

Restoring manifests does not reverse database migrations, persistent-volume writes, or external changes made by the failed release. Treat Helm rollback as the Kubernetes resource recovery step, then confirm the rollout and application response before reopening normal traffic.

Related: How to upgrade a Helm release on Kubernetes
Related: How to install a Helm chart on Kubernetes
Related: How to roll back a Kubernetes Deployment

Steps to roll back a Helm release on Kubernetes:

  1. List the release revisions in the namespace that contains the failed release. 
    $ helm history web --namespace team-a
REVISION    UPDATED                  STATUS        CHART       APP VERSION    DESCRIPTION
1           Fri Jun 26 20:52:45 2026 superseded    web-0.1.0   1.0.0          Install complete
2           Fri Jun 26 20:52:52 2026 deployed      web-0.1.0   1.0.0          Upgrade complete

    The row with status deployed is the active release. Choose an earlier superseded revision only after matching it to the last working application release.

  2. Roll back the release to the selected revision and wait for supported resources to become ready. 
    $ helm rollback web 1 --namespace team-a --wait --timeout 2m
Rollback was a success! Happy Helming!

    Helm can target the previous release when the revision is omitted or set to 0, but an explicit revision keeps the recovery target visible in shell history. --wait waits up to --timeout for supported resources to become ready.

    Helm restores Kubernetes manifests only. It does not reverse database migrations, persistent-volume writes, or external service changes from the failed release.

  3. Confirm that Helm recorded the rollback as a new deployed revision. 
    $ helm history web --namespace team-a
REVISION    UPDATED                  STATUS        CHART       APP VERSION    DESCRIPTION
1           Fri Jun 26 20:52:45 2026 superseded    web-0.1.0   1.0.0          Install complete
2           Fri Jun 26 20:52:52 2026 superseded    web-0.1.0   1.0.0          Upgrade complete
3           Fri Jun 26 20:52:53 2026 deployed      web-0.1.0   1.0.0          Rollback to 1

    The restored manifest comes from revision 1, while the rollback itself is stored as the newest release revision.

  4. Check the release status and restored workload availability. 
    $ helm status web --namespace team-a
NAME: web
LAST DEPLOYED: Fri Jun 26 20:52:53 2026
NAMESPACE: team-a
STATUS: deployed
REVISION: 3
DESCRIPTION: Rollback to 1
RESOURCES:
==> v1/Deployment
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    1/1     1            1           8s
##### snipped #####
  5. Wait for the Deployment rollout to finish. 
    $ kubectl rollout status deployment/web --namespace team-a --timeout=120s
deployment "web" successfully rolled out

    If the rollout times out, inspect recent events and pod logs before forcing another change.
    Related: How to check Kubernetes events

  6. Run the application smoke check against the rolled-back workload. 
    $ kubectl exec deployment/web --namespace team-a -- wget -qO- http://127.0.0.1
release=good-v1

    Replace the local Nginx request with the application health endpoint, login check, synthetic transaction, or service-level probe that proves the restored release behaves like the known-good version.