skip to content

Rollback & History

4 roadmaps4 questions

helm history lists revisions and helm rollback restores one — as a new revision, not by rewinding the counter. What it cannot undo — migrated data, a deleted PVC — is the senior half.

part ofHelmoverview, primer and where to startread it →
on this pageshow

explore

questions

4

What does `helm history` print for a release, and what does each column tell you?

level: juniorimportance: must knowfreq 74%

answer

  1. One row per completed operation
  2. The counter never goes backwards
  3. Two different version columns, two owners
  4. Exactly one row should read deployed
  5. Old rows are pruned, so reach is bounded

basics

~20 s

helm history <release> prints one row per stored revision: the revision number, when it was written, its status (deployed, superseded, failed or a pending state), the chart name with its chart version, the app version, and a description.

solid answer

~50 s

`helm history <release>` prints the release's revision ledger, oldest first. **REVISION** is a counter that increments on every install, upgrade and rollback. **UPDATED** is when that record was written. **STATUS** is that revision's outcome — `deployed` for the one Helm believes is live, `superseded` for one that was replaced, `failed`, or a `pending-*` state left by an operation that never finished. **CHART** is the chart name joined to its `version`; **APP VERSION** is the chart's `appVersion`, the packaged software's version, which moves independently of the chart version. **DESCRIPTION** is Helm's own note: "Install complete", "Upgrade complete", "Rollback to 44", or the error text on a failed revision. It is the fastest read of what happened to a release, and of how far back you can still roll: history is pruned to a configured limit, so early revisions may simply be gone.

code

bash · 10 lines
bash
# revision ledger for one release, in one namespace
helm history indexer-platform -n search

# bound the rows, or take it as data
helm history indexer-platform -n search --max 5
helm history indexer-platform -n search -o json

# what actually changed between two revisions
diff <(helm get manifest indexer-platform -n search --revision 46) \
     <(helm get manifest indexer-platform -n search --revision 47)

go deeper

for a junior

Be ready to name the columns and say what the revision counter counts — one row per install, upgrade or rollback of that release in that namespace. Know that deployed marks the current one and superseded marks one that was replaced.

for a middle

Explain the two version columns as separate owners: version in the chart packaging versus appVersion for the software, and which one a --version constraint resolves against. Be able to say what the DESCRIPTION field carries on a failed revision.

for a senior

Show that you read the table as an incident timeline: a failed row, a pending row and a lower chart version after a higher one each tell a different story. Say out loud that deployed is a record of a successful write, not evidence of a healthy workload.

for a principal

Own the consequence of bounded history: rollback reach is a policy decision, and a release upgraded many times a day keeps only minutes of it. Be ready to argue what your recovery story is when the revision you want has been pruned.

## What history actually is Helm does not diff your cluster against a chart to work out what a release is. It keeps a record per **revision** — a numbered, immutable snapshot of one completed operation — in the release's namespace, and `helm history` reads those records back. The revision counter starts at 1 with the install and increments by one for every `helm upgrade` and every `helm rollback` that runs to completion, successfully or not. Nothing ever rewrites an existing revision, so history is an append-only ledger of what was asked of this release. ``` $ helm history indexer-platform -n search REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 44 Mon Mar 3 09:12:41 2026 superseded indexer-platform-4.11.7 2026.2.19 Upgrade complete 45 Mon Mar 3 14:38:02 2026 superseded indexer-platform-4.12.0 2026.2.19 Upgrade complete 46 Tue Mar 4 08:03:55 2026 deployed indexer-platform-4.13.2 2026.3.1 Upgrade complete 47 Tue Mar 4 08:31:19 2026 failed indexer-platform-4.14.0 2026.3.4 Upgrade "indexer-platform" failed: ... ``` ## Column by column **REVISION** — the integer identity of the snapshot. It is not a chart version and not a Deployment's rollout revision; it counts Helm operations on this release name in this namespace, and nothing else. **UPDATED** — the local timestamp at which the record was written. Useful for correlating a release change with an incident timeline, and for spotting a revision that was written days after the pipeline claims it shipped. **STATUS** — the outcome of that operation. The values you meet are `deployed` (the revision Helm considers current), `superseded` (it was deployed once and a later revision replaced it), `failed` (the operation errored), the `pending-install` / `pending-upgrade` / `pending-rollback` trio (an operation started and never wrote a terminal status — the client was killed, or it timed out), `uninstalling`, and `uninstalled` (which you only see when the release was removed with history kept). On a healthy release exactly one row reads `deployed`. **CHART** — the chart name joined to the chart's `version` field, for example `indexer-platform-4.13.2`. This is the packaging version that a `--version` constraint selects. **APP VERSION** — the chart's `appVersion`, which names the software the chart packages. It is free-form, is not required to be semver, and is not what any Helm flag matches on. Two revisions can share an app version while the chart version moves (a templating fix) or share a chart version while the app version moves (an image bump driven purely by values). Confusing the two columns is the most common misread of this table. **DESCRIPTION** — the note Helm attached. On success it is a canned string; on a rollback it reads `Rollback to 44`, which is how you tell a rollback revision from an upgrade at a glance; on a failure it carries the error message from the operation, which is often the whole diagnosis without any further command. ## Reading it in anger Three questions get answered from this table. *What is live?* — the `deployed` row, and its chart version tells you which chart was applied, not what a Git branch currently says. *What happened?* — the sequence of statuses and descriptions; a `failed` row followed by a `deployed` row at a lower chart version is a rollback story, and a trailing `pending-upgrade` means the release is wedged rather than merely broken. *How far back can I go?* — only revisions still listed. Helm prunes old revisions to a maximum history depth when it writes a new one, so on a busy release the row you wanted from last month is gone, and no flag resurrects it. The command is scoped like every other Helm command: a release name is unique per namespace, so `-n` matters, and `helm history` accepts `-o json` or `-o yaml` for scripting plus a `--max` to bound the rows. ## What it does not tell you History is a record of *operations*, not of *health* and not of *reality*. A `deployed` status means Helm's last write succeeded, not that the pods are Ready; check the workloads for that. It also does not show what changed between two revisions — for that, fetch the stored manifest of each revision and diff them. And it records no author: it is not an audit trail of who ran the upgrade, only of what the release became.

  • The CHART column shows 4.13.2 and APP VERSION shows 2026.3.1. Which one does a --version constraint on an upgrade match?
    The chart version — the `version` field in `Chart.yaml`, which is what the CHART column concatenates onto the chart name. `appVersion` is metadata describing the software the chart packages; it is free-form, need not be semver, and no Helm flag resolves against it. A chart can ship several revisions at the same `appVersion` while its own version moves for templating fixes, and vice versa.
  • helm history shows a revision stuck at pending-upgrade. What does that status mean about the operation?
    It means Helm wrote the record marking the operation started and never wrote a terminal status — the CLI was killed, the pipeline runner was evicted, or the process died mid-flight. It is not a transient display: the record stays that way, and Helm's pessimistic lock treats the release as busy, so the next upgrade is refused with "another operation (install/upgrade/rollback) is in progress" until the release is moved out of that state.
  • Your release has run for a year but helm history lists only ten rows. Why, and what does it cost you?
    Helm prunes old revisions when it writes a new one, keeping a bounded number of records (ten by default). It costs you reach: you can only roll back to a revision that still exists, so "go back to what we ran in January" is not available from history alone. If you need that, the recovery path is to install the older chart version and values forward, not to roll back.

saying these in an interview costs you the question

  • Thinking APP VERSION is the chart version
  • Reading the revision number as a chart version
  • Assuming deployed means the pods are healthy
  • Believing history keeps every revision forever
  • Confusing a Helm revision with a Deployment rollout revision
  • Expecting history to show who ran the upgrade

context

resolving links…

open as a page

After `helm rollback 3` on a release at revision 5, which revision is the release on?

level: middleimportance: must knowfreq 66%

basics

~10 s

Revision 6. helm rollback never rewinds the counter: it appends a new revision holding revision 3's content, marks revision 5 superseded, and leaves 3, 4 and 5 in history with their original numbers.

open as a page

Does `helm rollback` re-render the chart, and can it work if that chart version is gone?

level: middleimportance: should knowfreq 54%

basics

~20 s

No re-render. Each revision record carries the chart, the supplied values and the fully rendered manifest, and helm rollback re-applies that stored manifest. Nothing is fetched, so a deleted chart version or an unreachable repository does not block a rollback.

open as a page

A `helm rollback` reports success on a 41-service platform chart, yet the incident continues. What does a rollback not restore?

level: seniorimportance: should knowfreq 46%

basics

~20 s

A rollback re-applies a stored manifest, so it restores only what that manifest describes. Data a workload already wrote, volume contents, CRDs installed from crds/ and anything outside the cluster stay as they are — and rendered credentials are reverted, which can be worse.

open as a page