skip to content

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

level: middleimportance: must knowfreq 66%

answer

  1. Think ledger, not checkout
  2. Every completed operation takes the next number
  3. The target revision keeps its old status
  4. The description line names the source revision
  5. Omitting the number means one step back, not back to good

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.

solid answer

~40 s

The release ends up on **revision 6**, whose content is a copy of revision 3. `helm rollback` is a forward operation: it reads the target revision's stored record, writes it back as the next number, and marks the previously deployed revision superseded. Revisions 3, 4 and 5 are untouched — history is append-only, which is what makes it an honest ledger, and `helm history` labels the new row `Rollback to 3`. Two consequences bite in practice. First, the revision you rolled back *to* is still `superseded`; the live one is 6. Second, `helm rollback` with no revision argument means *the immediately previous revision*, so running it again now produces revision 7 as a copy of revision 5 — the bad one you just escaped. Always name the target revision explicitly.

code

bash · 8 lines
bash
# release is at revision 5; name the target explicitly
helm rollback indexer-platform 3 -n search

# the release is now on revision 6, holding revision 3's content
helm history indexer-platform -n search

# DANGEROUS after the rollback above: 'previous revision' is now 5
# helm rollback indexer-platform -n search   # would create 7 from 5

go deeper

for a junior

Remember the shape: a rollback creates the next revision number holding an older revision's content. If asked what the release is on afterwards, answer with the new number, not the number you targeted.

for a middle

Explain why the ledger is append-only — a rollback is an operation that can fail and must record itself — and what the history row then shows: a lower chart version at a higher revision, described as a rollback to the source revision.

for a senior

Demonstrate the incident habit: read helm history first, name the target revision explicitly, and never fire a bare rollback twice, because the second one restores the revision you just escaped. Know when the target has been pruned and the real move is an install-forward.

for a principal

Own the recovery policy: how deep history should be for the release cadence you run, whether rollback or roll-forward is your declared default, and how a rollback executed by hand is reconciled with whatever system believes it owns the desired state.

## Rollback moves forward The mental model people arrive with is a version-control checkout: `helm rollback 3` sounds like it should put the release back *at* revision 3. It does not. Helm's release history is append-only, and every completed operation — install, upgrade, and rollback alike — consumes the next number. `helm rollback my-release 3` on a release at revision 5 therefore produces **revision 6**, whose stored content is a copy of revision 3's, and the release is now "on 6". After the operation, `helm history` reads: ``` REVISION STATUS CHART DESCRIPTION 3 superseded indexer-platform-4.11.7 Upgrade complete 4 superseded indexer-platform-4.12.0 Upgrade complete 5 superseded indexer-platform-4.13.2 Upgrade complete 6 deployed indexer-platform-4.11.7 Rollback to 3 ``` Three things are worth noticing. Revision 6 carries the *chart version of its source*, 4.11.7, so the CHART column shows a version going backwards while the revision number goes forwards. The `Rollback to 3` description is how you distinguish a rollback from an ordinary upgrade later. And revision 3 itself is still `superseded` — rollback did not reactivate it, it copied it. ## Why append-only A rollback is a change to a live cluster, and it can fail exactly like an upgrade can: an object may be rejected, a webhook may deny it, the API server may be unreachable halfway through. If rollback rewound the counter, a failed rollback would have nowhere to record itself and the ledger would lie about what was attempted. Appending keeps three properties: every attempt is recorded with its own status, the current state is always the highest numbered terminal revision, and the sequence of operations can be reconstructed after the fact. It also means you can roll back *a rollback* — the operation composes, because it only ever reads an old record and writes a new one. ## The bare-rollback trap `helm rollback RELEASE` with the revision omitted means "the previous revision", which is the current number minus one. That is intuitive right after a bad upgrade: at revision 5, a bare rollback restores 4 as revision 6. It stops being intuitive immediately afterwards. Once you are on revision 6 (a copy of 3), the previous revision is 5 — the bad one. A second bare `helm rollback` therefore creates revision 7 as a copy of 5 and puts the failure straight back into production. In an incident, always pass the revision number you actually want, and read it off `helm history` first rather than counting in your head. ## How far back you can go Rollback can only target a revision that still exists. Helm keeps a bounded number of revision records and prunes the oldest as it writes new ones, so a release upgraded on every merge may hold only the last handful. "Roll back to what we shipped last quarter" is usually not a rollback at all; it is an install-forward of that older chart version and values, done as a normal upgrade. It is worth knowing which of the two your recovery runbook actually describes. ## Manual rollback versus rollback on failure `helm rollback` is a deliberate, separate command a human or a pipeline runs after the fact. It is not the same thing as asking an upgrade to undo itself when it fails; that is a flag on the upgrade, it happens inside the same invocation, and it is a different leaf of behaviour. What they share is the revision arithmetic: an automatic undo also appends a new revision rather than deleting the failed one, so a release that self-recovered still shows the failed attempt in its history. If your history looks like `failed`, then `deployed` at the older chart version, something rolled you back — the description tells you which revision it targeted. ## Reading the outcome A successful rollback prints the new revision number, and that number is the thing to quote in the incident channel — "we are on revision 6, which is revision 3's content", not "we are back on 3". The distinction matters when someone later greps the pipeline logs for which chart version is live: the CHART column of revision 6 answers that, while the revision number alone does not. It also matters for the next upgrade, which will be numbered 7 and will build on 6's stored values, not on the values of the revision you abandoned.

  • Why does Helm append a revision for a rollback instead of deleting the revisions in between?
    Because a rollback is itself an operation that can fail, and the history has to record attempts, not just outcomes. Appending keeps one record per attempt with its own status, keeps the current state at the highest terminal revision, and makes the ledger reconstructable afterwards. Deleting revisions would also destroy the evidence of what was tried during an incident, which is usually the most valuable part of the record.
  • After rolling back, what chart version does helm history show for the new revision?
    The chart version of the revision it copied. So the CHART column moves backwards — for example from `indexer-platform-4.13.2` on revision 5 to `indexer-platform-4.11.7` on revision 6 — while the revision number moves forwards. That pairing, a lower chart version at a higher revision number with a `Rollback to N` description, is the signature of a rollback in the ledger.
  • A teammate says the fix is to roll back to the chart version we ran six weeks ago. What do you check first?
    Whether that revision still exists in `helm history`. Helm prunes old revision records as it writes new ones, so on a frequently upgraded release the target may be gone, and rollback simply cannot reach it. If it has been pruned, the recovery is an install-forward: run `helm upgrade` pinned to that older chart version with the values that produced it, which is a new revision built from the chart, not a replay of a stored one.

saying these in an interview costs you the question

  • Saying rollback resets the release to revision 3
  • Claiming rollback deletes revisions 4 and 5
  • Thinking a bare rollback returns to the last good revision
  • Assuming a rollback revision cannot itself fail
  • Believing you can roll back to any revision ever created

context

resolving links…