After `helm uninstall`, a Job created by a chart's pre-install hook is still in the namespace. Why?

### Two lists, not one When Helm renders a chart it sorts the rendered manifests into two piles. Anything carrying the `helm.sh/hook` annotation is pulled out and recorded as a **hook**; everything else becomes the release **manifest**. Only that manifest is the release's tracked desired state — it is what an upgrade diffs, what `helm get manifest` prints, and what `helm uninstall` walks when it deletes. The hooks are stored beside it in the release record and replayed at the events they ask for. `helm get hooks <release>` prints them, and it keeps printing them long after the live objects are gone, because it is reading stored YAML rather than the cluster. ### Uninstall only walks the manifest Deletion is driven by that tracked manifest, so a hook object was never a candidate for removal in the first place. A pre-install Job that ran once, completed, and was never given a delete policy simply stays: the Job object, its Pods and their logs remain in the namespace after the release is gone. The same is true of everything else a hook renders — the ServiceAccount it runs as, the Role that lets it read a Secret, a ConfigMap holding the SQL it applies. None of it is release-managed, so none of it is release-deleted. ### The default policy has the wrong timing to help With no `helm.sh/hook-delete-policy` annotation, Helm behaves as if `before-hook-creation` were set. That value deletes an existing object of the hook's kind and name *immediately before Helm creates that hook again*. It is a pre-cleanup, and it fires only on the next run of that hook. After an uninstall there is no next run, so the default never fires and the object survives indefinitely. Most people who claim "Helm cleans hooks up automatically" are thinking of this policy and have missed that its trigger is the next install or upgrade, not teardown. ### Making a hook clean up after itself The completion-time policies are the fix, and they are set on the hook manifest itself: ```yaml metadata: name: order-checkout-seed annotations: "helm.sh/hook": pre-install "helm.sh/hook-delete-policy": hook-succeeded,hook-failed ``` `hook-succeeded` removes the object as soon as Helm judges the hook successful; `hook-failed` removes it when the hook fails. List both and the object never outlives its own run, so there is nothing for uninstall to leave behind. The cost is debuggability: with `hook-failed` set, the failed Job and its Pod logs vanish at exactly the moment you want to read them, which is why many charts settle on `before-hook-creation,hook-succeeded` and deliberately keep failures around for a human. Helm's own documentation also points at Kubernetes' time-to-live field on a Job as an alternative reaper for finished Jobs. ### Objects a hook creates at runtime are worse Everything above concerns objects Helm renders and applies. If the hook's own process calls the cluster API and creates something — a temporary Secret for a one-off credential, a debug Pod — Helm has no record of it at all, no annotation can govern it, and no policy will remove it. That work has to be undone by the hook itself, or by a delete-phase hook that carries its own delete policy so it does not become another leftover. ### A worked example A multi-tenant chart for an order-checkout API is installed once per team namespace, fourteen namespaces in all. Each release runs a pre-install Job that seeds reference data. Nobody annotated it, so every namespace accumulates one completed Job per install. A team decommissions its namespace's release with `helm uninstall`; `helm list` shows nothing, but `kubectl get jobs -n team-checkout-7` still shows the seed Job and one `Completed` Pod. Reinstall six weeks later and the picture gets confusing: the default `before-hook-creation` does delete that stale Job at last — because the hook is running again — so the leftover quietly disappears at the least informative moment, and the team concludes uninstall had cleaned it up all along. ### What to check when you see one Run `helm get hooks <release>` (or read the chart) and look at the annotations on the hook in question. If there is no `helm.sh/hook-delete-policy`, or it lists only `before-hook-creation`, the object is meant to survive between runs and nothing will remove it once the release is gone. Decide per hook whether the artefact is evidence you want to keep or litter you want gone, then say so in the annotation rather than deleting objects by hand after every teardown.