How does Helm's --atomic flag change the stuck-release failure mode, and what window of risk does it not actually cover?

--atomic makes Helm automatically roll back to the previous successful release if the upgrade fails during Helm's own execution — genuinely eliminating the "upgrade failed, now I have to manually decide what to do" scenario for failures Helm itself detects and can respond to. What it doesn't cover is the process running helm upgrade --atomic itself being killed (CI job timeout, OOM, manual cancellation) — if the helm process is terminated before it can complete either the upgrade or the automatic rollback it would have triggered, the release can still end up stuck in a pending-upgrade state, exactly like the non-atomic case.

--atomic works by having Helm itself watch the upgrade's progress and, if it detects a failure (a resource fails to apply, a hook fails, a readiness check configured via --wait times out), automatically trigger a rollback to the last successful release — all within that same helm upgrade --atomic invocation. This directly solves the failure mode where an upgrade fails and the release is left in a broken, "someone needs to manually decide whether to rollback or retry" state — --atomic makes that decision automatically and immediately, without waiting for a human to notice and intervene.

What --atomic fundamentally can't cover is the case where the process itself — the helm CLI invocation — is externally terminated before it can complete either the upgrade or its own automatic rollback response. If a CI job running helm upgrade --atomic is killed by a job timeout, an OOM kill on the CI runner, or a manual cancellation, Helm never gets the chance to detect the failure and trigger the rollback it would otherwise have performed — the release is left in whatever intermediate state it was in in the moment of termination, which can still be the same ambiguous pending-upgrade status as the original non-atomic stuck-release scenario. --atomic protects against failures Helm can observe and respond to while running; it provides no protection against the running process itself being cut off.

This is an important distinction for interview purposes specifically because --atomic is often (incorrectly) treated as a complete solution to Helm's stuck-release problem — it meaningfully reduces the risk surface (many failures genuinely are caught and auto-rolled-back), but the "CI job got killed mid-deploy" scenario, which is a common real-world cause of stuck releases, sits entirely outside what --atomic can address, since it requires the Helm process itself to still be alive and executing to do anything at all.

• --atomic automatically rolls back on a failure Helm itself detects during the upgrade — a real, meaningful improvement over manual intervention.
• It provides no protection against the helm process itself being externally killed (CI timeout, OOM, cancellation) before it can complete or roll back.
• A killed --atomic invocation can leave a release stuck in the same pending-upgrade state as the non-atomic case — --atomic doesn't eliminate the stuck-release failure mode entirely.
• Treating --atomic as a complete solution rather than a partial mitigation is a common, worth-correcting misconception.

• Helm CLI: helm upgrade — --atomic
• Helm: Release Metadata / Storage backends