helm status: Usage, Options & Common CI Errors
Inspect a single release: state, resources, and notes.
helm status reports the current condition of one release - its deployment status, the resources it owns, and the rendered NOTES.txt. It is the targeted view that complements the list overview.
What it does
helm status NAME prints the release's status (deployed, failed, pending-upgrade, etc.), last-deployed time, and notes. --show-resources lists the Kubernetes objects in the release with their state; --revision inspects a specific past revision. It errors if the release does not exist, which makes it a clean existence check.
Common usage
helm status web -n prod
helm status web --show-resources
helm status web --revision 3
helm status web -o jsonCommon errors in CI
A status of pending-install or pending-upgrade that never clears means a prior helm command was interrupted (CI cancelled mid-deploy) - the release is stuck and the next upgrade reports "another operation (install/upgrade/rollback) is in progress". helm status surfaces that state so you can intervene (roll back or, as a last resort, clear the pending state). "Error: release: not found" is a definitive "this release does not exist here", more reliable than scraping helm list output for existence in scripts.
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.
# 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