How to know more details about a previous rollout revision using kubectl?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Kubernetes tracks revision history for Deployments, StatefulSets, and DaemonSets. To inspect a previous rollout revision, use kubectl rollout history deployment/<name> --revision=<number>, which shows the pod template, container images, environment variables, and annotations for that specific revision. This is essential for debugging failed deployments, understanding what changed between releases, and deciding whether to roll back.
Viewing Rollout History
List all recorded revisions for a deployment:
The CHANGE-CAUSE column is populated from the kubernetes.io/change-cause annotation. If no annotation exists, it shows <none>.
Inspecting a Specific Revision
Use the --revision flag to see full details of any revision:
This shows the exact pod template — container image, ports, environment variables, volumes, and labels — for that revision.
Setting Change-Cause Annotations
Record why a change was made by setting the kubernetes.io/change-cause annotation:
Without this annotation, CHANGE-CAUSE shows <none>, making it difficult to understand what each revision changed.
Comparing Revisions
Kubernetes does not have a built-in diff command, but you can compare revisions using output redirection:
For a more structured comparison, use JSON or YAML output with kubectl get:
Rolling Back to a Previous Revision
Once you identify the revision you want, roll back to it:
Rolling back creates a new revision number (e.g., revision 4) with the same pod template as revision 2. The original revision 2 is removed from history.
Controlling Revision History Limits
By default, Kubernetes keeps 10 revisions. Control this with revisionHistoryLimit:
Each revision corresponds to an old ReplicaSet object. Setting revisionHistoryLimit: 0 disables rollback capability entirely.
Rollout History for Other Resource Types
The same commands work for StatefulSets and DaemonSets:
Common Pitfalls
- Missing
CHANGE-CAUSEin history: The--recordflag is deprecated since Kubernetes 1.25. Usekubectl annotatewithkubernetes.io/change-causeafter each update to record meaningful change descriptions. - Revision history is empty or shows only one entry: The
revisionHistoryLimitdefaults to 10, but if set to a low number (or 0), old revisions are garbage collected. Check.spec.revisionHistoryLimitin the deployment spec. - Rolling back does not restore the old revision number: A rollback to revision 2 creates a new revision (e.g., 4) and removes revision 2 from history. This can be confusing when tracking changes — always check
kubectl rollout historyafter a rollback. - Expecting
--revisionto show diff between revisions: The--revisionflag shows a single revision's details, not a comparison. To compare, redirect two revisions to files and usediff. - ConfigMap/Secret changes not triggering new revisions: If you update a ConfigMap or Secret referenced by a deployment, the deployment does not get a new revision unless the pod template itself changes. Use a hash annotation pattern (e.g.,
checksum/config) to force new revisions when configs change.
Summary
kubectl rollout history deployment/<name>lists all recorded revisionskubectl rollout history deployment/<name> --revision=Nshows full pod template details for revision N- Annotate deployments with
kubernetes.io/change-causeto record why each change was made kubectl rollout undo --to-revision=Nrolls back to a specific revision- Set
revisionHistoryLimitto control how many old ReplicaSets are retained - Compare revisions by saving
--revisionoutput to files and usingdiff

