Helm Rollback Duration Calculator
Estimate how long a `helm rollback` takes, combining revision lookup, manifest re-apply, and pod restart time.
Inputs
Time to fetch the target revision's stored manifest from the storage backend.
Time for the API server to apply the reverted manifests.
Time for affected pods to terminate, reschedule, and become ready again.
Total Rollback Time
32.0sec
Total Rollback Time
0.53min
Pod Restart Share of Total Time
78.1%
Step by step
Total = lookup + apply + pod restart
1s + 6s + 25s
= 32.0s
Total in minutes
32.0s ÷ 60
= 0.53 min
How it works
`helm rollback` reverts a release to a previously stored revision: Helm looks up that revision's manifest from its storage backend, re-applies it as a new revision, and Kubernetes then has to terminate current pods and bring up pods matching the reverted spec. Pod restart time — driven by image pulls, container startup, and readiness probes — is almost always the dominant cost, dwarfing the near-instant revision lookup and apply steps.
Formula
totalTime = revisionLookup + manifestApply + podRestart
- t_l
- Revision lookup time in seconds
- t_a
- Manifest apply time in seconds
- t_r
- Pod restart time in seconds
- T
- Total rollback time in seconds
Frequently Asked Questions
Is `helm rollback` guaranteed to be faster than a fresh upgrade?
Usually yes for the render/diff overhead, since the manifest is already stored, but pod restart time is comparable to an upgrade because Kubernetes still has to reschedule and re-ready the pods for the reverted spec.
Do rollbacks re-run hooks?
By default Helm 3 does not run most hooks on rollback unless explicitly configured; the `--no-hooks` behavior varies by hook type, so pre/post-rollback hooks (if defined) can add to the duration.
How can I make rollbacks faster?
Keep readiness probes tight but accurate, pre-pull images used by recent revisions onto nodes, and avoid rollback targets that require large stateful pod restarts (e.g. StatefulSets with slow init containers).