# helm status: Command Reference for CI/CD

> Reference for helm status: inspect a release state, revision, and resources, machine-readable output for CI assertions, and a post-deploy verification example.

Source: https://latchkey.dev/learn/command-reference/helm-status-command-cli-reference  
Updated: 2026-06-26

Inspect a release current state, revision, and resources.

helm status reports a release deployment status, its current revision, and the resources it manages. In CI it is the verification read after a deploy and a script-friendly source of the release state. This reference covers its flags.

## Common flags and usage

- status <release>: show status, revision, and resources
- -o json|yaml: machine-readable output for CI assertions
- --revision N: show the status of a specific revision
- --show-resources: list the managed Kubernetes objects
- Pair with helm list to enumerate releases in a namespace

## Example

```shell
STATE=$(helm status web -n prod -o json | jq -r '.info.status')
[ "$STATE" = "deployed" ] || { echo "release not deployed: $STATE"; exit 1; }
```

## In CI

Assert on helm status -o json after a deploy to confirm the release reached the deployed state rather than failed or pending-upgrade. The JSON output is stable enough to parse with jq, making status the clean verification read at the end of a deploy job.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### helm status: Command Reference for CI/CD?

helm status reports a release deployment status, its current revision, and the resources it manages. In CI it is the verification read after a deploy and a script-friendly source of the release state. This reference covers its flags.

### In CI?

Assert on helm status -o json after a deploy to confirm the release reached the deployed state rather than failed or pending-upgrade. The JSON output is stable enough to parse with jq, making status the clean verification read at the end of a deploy job.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt