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

### Why the order matters Inheriting a live release is an exercise in reducing uncertainty in the cheapest order. Every command below is read-only, so the risk is not in running them - it is in changing a release before you have run them. The sequence moves from "does this thing exist and where" to "what exactly did Helm apply", and each step narrows what the next one has to explain. Take a concrete case. A geospatial tile server runs as the release `tileserv`, and the only thing anyone can tell you is that it was installed from "the platform chart". ### 1. Establish existence, namespace and identity ``` $ helm list -A --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 ``` One row answers four questions: the release lives in `geo`, it has been through 27 revisions, revision 27 came from chart `tile-platform` version 4.2.1, and Helm believes the last operation succeeded. `-A` matters here because you were not told the namespace, and a listing without it would have told you the release did not exist. Note what is *not* answered: `tile-platform` is an 18-chart umbrella bundling an API subchart and a worker subchart, and none of those subcharts appear as releases. The whole umbrella is this one row. ### 2. Read the current state `helm status tileserv -n geo` reports the release's status, the revision, when it was last deployed, the description Helm recorded for the last operation, and the rendered notes. That description is often the fastest signal available - it is where a message such as an upgrade failure reason ends up. In **Helm 4** it always prints; the Helm 3 flags `--show-desc` and `--show-resources` were removed, so a habit of typing them produces an unknown-flag error rather than more output. `--revision` lets you read the status Helm recorded for an earlier revision. ### 3. Pull the record apart Now read the stored artefacts, cheapest and most structured first: - `helm get metadata tileserv -n geo -o json` - a compact summary: name, namespace, revision, chart name and version, appVersion, status, deployment time. Ideal when you are recording the state in a ticket or feeding a script. - `helm get values tileserv -n geo` - the overrides a human actually supplied at the last operation. This is the shortest document in the whole investigation and usually the most revealing, because it is the list of decisions someone made deliberately. - `helm get values tileserv -n geo --all` - the computed tree the templates rendered against, including all eighteen subcharts' defaults. Reach for it when a manifest field has no explanation in the user-supplied set. - `helm get manifest tileserv -n geo` - the YAML Helm applied for revision 27, exactly as stored. - `helm get hooks tileserv -n geo` - the work attached to events, which never appears in the manifest and is easy to forget exists. `helm get all` gives you every one of these in a single stream when you would rather read once than five times. ### 4. Ask what changed Because every one of these accepts `--revision`, the previous revision is one flag away: ``` $ helm get manifest tileserv -n geo --revision 26 > r26.yaml $ helm get manifest tileserv -n geo --revision 27 > r27.yaml $ diff -u r26.yaml r27.yaml ``` That diff is a statement about what the last upgrade actually changed in the applied set - built entirely from what Helm stored, so it stays true even though the chart repository has moved on since. ### The judgement being tested Three things separate a senior answer. **The chart in your repository is not necessarily the chart that is running.** The release holds chart version 4.2.1; `main` may be at 4.6.0. Anything you conclude by reading the chart source without checking the recorded version is a guess. **"deployed" is a record, not a health check.** It means Helm's last operation completed. It is not evidence that the tile server is serving requests, and it is not evidence that the live objects still match the stored manifest - checking that is a separate exercise with different tools. **Read before you write.** The reason this is asked at all is that the expensive incidents start with an upgrade run against a release whose overrides nobody had looked at: an emergency `--set` from six months ago is still in the user-supplied values, and the upgrade either preserves a setting you did not know about or drops one you needed. Ten read-only commands cost a minute; discovering the override afterwards costs an outage.