skip to content

Inspecting a Release

4 roadmaps4 questions

What is actually installed: listing releases, reading a release's status, and pulling back the manifest, values and hooks it holds. Probed because nobody should change a release they have not read.

part ofHelmoverview, primer and where to startread it →
on this pageshow

explore

questions

4

What does `helm list` show by default, and how do its namespace and status flags change that?

level: juniorimportance: must knowfreq 76%

answer

  1. Helm's own records, not cluster objects
  2. Which namespace are you looking at
  3. One flag for all namespaces, one that is gone
  4. Status flags subtract in Helm 4
  5. Two version columns, only one is the chart

basics

~20 s

helm list shows releases in one namespace - the current kube context's, or the one -n names; -A lists every namespace. Helm 4 lists all statuses by default, so flags like --failed narrow the list rather than widening it.

solid answer

~40 s

`helm list` enumerates Helm's own release records, not cluster objects. It is **namespace-scoped**: with no flag it lists the namespace your kube context selects, `-n geo` lists that one, and `-A`/`--all-namespaces` lists every namespace you can read - which is why a release that seems to have vanished is usually just in another namespace. Each row is one release: NAME, NAMESPACE, REVISION, UPDATED, STATUS, CHART (chart name plus chart version) and APP VERSION (the chart's `appVersion`, informational only). In **Helm 4** the default listing already includes every status, and the status flags - `--deployed`, `--failed`, `--pending`, `--superseded`, `--uninstalled`, `--uninstalling` - *narrow* it. Helm 3's `-a`/`--all`, which widened the list, was removed; `-A` is a different flag. Use `--filter` for a name regex and `-o json` when a script reads the output.

code

bash · 14 lines
bash
# Releases in the namespace the current context selects
helm list

# One explicit namespace, then every namespace you can read
helm list -n geo
helm list -A

# Helm 4: status flags NARROW the default listing
helm list -n geo --failed
helm list -n geo --pending

# Name regex, and structured output for scripts
helm list -A --filter '^tileserv$'
helm list -A -o json

go deeper

for a junior

Be ready to say that helm list looks at one namespace unless you pass -A, and to name the columns. Knowing that a 'missing' release is nearly always a namespace mistake is most of the value here.

for a middle

Explain that the rows come from Helm's stored release records rather than a cluster query, and that in Helm 4 the status flags narrow the listing while Helm 3's -a widened it. Name the statuses you can see.

for a senior

Show the operational reflex: -A plus --filter to find a release fast, -o json for anything automated, and the discipline of not reading 'deployed' as 'healthy'. Explain why an umbrella install is one row.

for a principal

Own the fleet view: helm list is per-cluster and per-context, so an estate-wide inventory needs something that runs it against every context or reads the records directly. Be ready to argue how you would standardise release naming and namespacing so that listing is unambiguous.

### What `helm list` is actually reading A Helm *release* is one named installation of a chart into one namespace. Helm keeps a record for each revision of each release, and `helm list` enumerates those records. It does not read your chart directory, and it does not ask the cluster what workloads are running. Every column it prints comes from what Helm itself stored the last time somebody installed, upgraded, rolled back or uninstalled that release. ### The default scope is a single namespace `helm list` is namespace-scoped. With no flag it lists releases in the namespace the current kube context selects (or the one `HELM_NAMESPACE` names); `-n geo` lists that namespace instead; `-A` (`--all-namespaces`) lists every namespace you have permission to read. This is by far the most common reason an engineer reports that a release "disappeared" - it was installed into `geo` and they are looking at `default`. Release names are unique *per namespace*, not per cluster. `tileserv` may legitimately exist in three namespaces at once, installed from three different chart versions, and only `-A` shows all three; the NAMESPACE column is what tells them apart. ### The columns, and the two versions people confuse A row carries NAME, NAMESPACE, REVISION, UPDATED, STATUS, CHART and APP VERSION. - **REVISION** is the release revision counter. Every successful install, upgrade or rollback increments it. It is not a chart version and not a Deployment's rollout revision. - **CHART** is the chart name joined to the *chart* version, e.g. `tile-platform-4.2.1` - the `version` field of `Chart.yaml` for the chart that this revision was installed from. - **APP VERSION** is that chart's `appVersion`: the version of the software the chart packages. It is descriptive metadata and nothing in Helm keys off it. Reading APP VERSION as "the chart version" is a classic slip. ### The statuses you will see STATUS is the lifecycle state Helm recorded: `deployed`, `failed`, `superseded` (an older revision replaced by a newer one), `uninstalling`, `uninstalled` (kept only when history was retained), and the pending states `pending-install`, `pending-upgrade` and `pending-rollback` that mark an operation Helm believes is still running. `deployed` means the last operation finished successfully - it is not a health check on the workloads. ### Status flags narrow; in Helm 3 one of them widened This is the change most likely to trip someone whose habits come from Helm 3. In Helm 3, `helm list` showed deployed and failed releases, and you added `-a`/`--all` to widen the result to every status. **Helm 4 removed `-a`/`--all` outright**: the default listing already includes every status, and the status flags now *narrow* it to the statuses you name. `helm list --failed` in Helm 4 means "only the failed ones", not "the usual list plus the failed ones". Reaching for `-a` gets you an unknown-flag error, and `-A` - all namespaces - is an unrelated flag that muscle memory happily substitutes. ### Shaping the output `--filter` takes a regular expression matched against release names. `-q` prints bare names. `-m`/`--max` and `--offset` page a long listing, `-d` sorts by last-updated instead of by name and `-r` reverses the order. `-o json` (or `yaml`) emits structured output - always the right choice when a script consumes the result, because the table's column widths shift with the data. ### A worked example A geospatial tile server runs in namespace `geo`, installed from an 18-chart umbrella called `tile-platform` that bundles an API subchart and a worker subchart: ``` $ helm list -n geo --filter '^tileserv$' NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION tileserv geo 27 2026-08-29 11:42:03 UTC deployed tile-platform-4.2.1 2026.8.3 ``` Read carefully what that single row claims. The release exists in `geo`, it is on revision 27, revision 27 came from chart version 4.2.1, and the last operation succeeded. It says nothing about the 18 subcharts inside the umbrella: subcharts are not separate releases and will never appear as their own rows, so an umbrella install is exactly one line however many charts it contains. And `deployed` describes Helm's record of the last operation, not whether the tile server is currently serving. ### Why interviewers ask it The question screens for whether a candidate understands that Helm's view of the world is a set of stored records scoped to a namespace, rather than a live inventory of the cluster. Someone who knows that listing is per-namespace, that one umbrella install is one row, and that Helm 4's status flags subtract rather than add, will not misdiagnose a release they simply cannot see.

  • In `helm list` output, what is the difference between the CHART and APP VERSION columns?
    CHART is the chart name joined to the chart's own `version` field, such as `tile-platform-4.2.1`. APP VERSION is that chart's `appVersion` - the version of the packaged software, which Helm records and prints but never acts on. Two releases can share an APP VERSION while running different chart versions, and a chart version bump with no application change leaves APP VERSION untouched.
  • Two teams each installed a release named `tileserv`. Can `helm list` show both at once?
    Yes, with `-A`. Release names are unique per namespace rather than per cluster, so the same name can exist many times over, and the NAMESPACE column distinguishes the rows. Without `-A` you see only the one in your current namespace, which is exactly how people convince themselves a colleague's release is missing.
  • How would you drive `helm list` from a script rather than reading its table?
    Use `-o json` or `-o yaml` and parse the structured output; the table is aligned for humans and its column widths move with the data. `-q` gives bare release names when that is all you need, `--filter` applies a name regex server-side of your pipeline, and `-m`/`--offset` page a long list. Combine with `-A` when the script should not depend on the caller's namespace.

saying these in an interview costs you the question

  • Thinks helm list is cluster-wide by default
  • Reaches for helm list -a, removed in Helm 4
  • Believes status flags widen the default listing
  • Confuses -A (all namespaces) with the removed -a
  • Reads APP VERSION as the chart version
  • Expects each subchart of an umbrella to get its own row

context

resolving links…

open as a page

What is the difference between `helm get values` and `helm get values --all` for a release?

level: middleimportance: should knowfreq 58%

basics

~20 s

helm get values prints only the overrides supplied at the last install or upgrade, as stored with that revision. --all prints the computed tree: those overrides merged over the chart's and subcharts' defaults, which is what the templates resolved against.

open as a page

You inherit a Helm release nobody documented - which commands establish what is deployed, and in what order?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Find it with helm list -A, read helm status for the current state and the last operation's description, then helm get metadata, values, values --all, manifest and hooks for the chart version, overrides and applied YAML - before changing anything.

open as a page

Why does `helm get manifest` omit a release's hook resources, and which command shows them?

level: middleimportance: nice to knowfreq 30%

basics

~20 s

Helm splits a render into ordinary manifests and hook manifests - anything carrying a helm.sh/hook annotation. Only the ordinary ones become the release manifest that helm get manifest prints; the hooks are stored separately and printed by helm get hooks.

open as a page