Short answer
No — --atomic does not reliably roll back when the Helm client is interrupted by SIGINT. In Helm 3 the rollback is initiated by the client process, not by a controller watching the release. Ctrl-C cancels the client's operation context, and the process normally exits before the rollback path completes. The practical rule: an interrupted --atomic upgrade is an unknown state that needs manual inspection, not an automatic revert.
Confirmed behavior versus version-dependent detail
Well-established Helm 3 facts:
--atomic implies --wait. The client watches applied resources until they report ready.--timeout (default 5m0s) is a client-side deadline for that wait and for hook Jobs. It does not cancel or revert anything in the cluster.- Rollback is a client-driven operation.
helm rollback runs from the client, and the atomic path reuses the same mechanism automatically.
- Kubernetes controllers reconcile independently of Helm. Once manifests are applied, a Deployment or StatefulSet keeps progressing even after the Helm process is gone.
Version-dependent, and therefore marked for review: exactly how far the client gets through its cleanup before exiting on SIGINT has changed across Helm 3 minor releases. Do not generalize a single observation.
Where the cancellation boundary sits
| Mechanism | Where it acts | Effect on the cluster |
|---|
--timeout | Client deadline | None by itself; only ends the wait |
--atomic | Client rollback trigger | Reverts only if the client runs it |
| SIGINT | Client process | Aborts in-process cleanup |
| Controller reconciliation | Server side | Continues toward last applied spec |
What state resources can be left in
- Applied manifests persist. The new spec is in the cluster and controllers keep working on it. A workload can become fully Ready after Helm already reported failure or was interrupted.
- The release record persists. By default a Secret named
sh.helm.release.v1.<release>.v<revision> in the release namespace, commonly showing pending-upgrade or failed.
- Interrupted during a pre-upgrade hook: hooks run before manifests are applied, so workloads are usually unchanged while the record sits at
pending-upgrade.
- First install via
helm upgrade --install --atomic: there is no previous revision, so the atomic path uninstalls the failed release instead of rolling back.
Recovery steps
- Confirm the client version, since interrupt handling is version-sensitive:
helm version
- Inspect the record:
helm history <release> -n <namespace>
- Check current status:
helm status <release> -n <namespace>
- Compare live objects:
kubectl get deploy,sts,pods -n <namespace>
- Revert deliberately to the last good revision:
helm rollback <release> <last-good-revision> -n <namespace>
If a rollback is itself interrupted, the release can end at failed or pending-rollback, which can block later upgrades until resolved. Avoid SIGKILL and avoid sending a second interrupt; both remove any chance of in-process cleanup.
Verification on a disposable cluster
helm version
helm upgrade --install demo ./chart --atomic --timeout 60s
# press Ctrl-C after roughly 10s
helm history demo -n default
helm status demo -n default
kubectl get deploy,sts,pods -n default
Repeat without interrupting and let the timeout expire, then compare whether a rollback revision appeared. Note also that --timeout does not bound total wall-clock time: hooks, image pulls and the rollback itself can extend it.
The one detail that changes the recommendation
Run helm version and check that minor release's notes before codifying a policy. On a Helm 3 minor where the interrupt path attempts a rollback before exit, an interrupted upgrade may already be reverted; on others it will not be. Without that version, the safe policy is: never rely on SIGINT for rollback, and always reconcile manually.
helm
kubernetes