# helm history: Usage, Options & Common CI Errors

> helm history lists a release's revisions with status and description. Picking a rollback target, --history-max pruning, and the no-revision errors in CI.

Source: https://latchkey.dev/learn/command-reference/helm-history-command  
Updated: 2026-06-25

See every revision of a release and what happened to it.

helm history shows the revision log for a release - each upgrade, rollback, and its outcome. You read it to pick a safe rollback target and to understand how a release reached its current state.

## What it does

helm history NAME lists revisions with their revision number, updated time, status (deployed, superseded, failed), chart, app version, and description. The newest deployed revision is the live one; superseded revisions are previous deployed states you can roll back to. --max limits the rows shown.

## Common usage

```Terminal
helm history web
helm history web -n prod --max 20
helm history web -o json
helm rollback web 5         # roll back to a revision history showed
```

## Common errors in CI

History is bounded: helm upgrade keeps at most --history-max revisions (default 10), so the revision you want to roll back to may already be pruned - history only ever shows what survives. A release whose history is all failed revisions has no good rollback target ("has no deployed releases"); you must fix forward with upgrade --install. "Error: release: not found" means the name/namespace is wrong, since history needs an existing release to report on.

## 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 history: Usage, Options & Common CI Errors?

helm history shows the revision log for a release - each upgrade, rollback, and its outcome. You read it to pick a safe rollback target and to understand how a release reached its current state.

### What it does?

helm history NAME lists revisions with their revision number, updated time, status (deployed, superseded, failed), chart, app version, and description. The newest deployed revision is the live one; superseded revisions are previous deployed states you can roll back to. --max limits the rows shown.

### Common errors in CI?

History is bounded: helm upgrade keeps at most --history-max revisions (default 10), so the revision you want to roll back to may already be pruned - history only ever shows what survives. A release whose history is all failed revisions has no good rollback target ("has no deployed releases"); you must fix forward with upgrade --install.

---

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