`kubectl logs --previous` Is the Flag You Forget Right Before a CrashLoop Steals the Evidence
A practical guide to `kubectl logs --previous` for developers and SREs who need to inspect terminated container output, debug CrashLoopBackOff behavior, and capture the logs that disappear between restarts.
Why this command matters: one of the most frustrating Kubernetes debugging moments is knowing a container definitely failed, then opening logs too late and only seeing the clean, new restart instead of the crash that mattered.
What kubectl logs --previous does
The Kubernetes docs for kubectl logs describe -p or --previous as printing the logs for the previous instance of the container in a pod, if it exists.
That sounds small, but operationally it is huge.
A normal logs command:
kubectl logs my-podshows the current container instance.
The previous-container form:
kubectl logs --previous my-podasks Kubernetes for the logs from the prior terminated instance.
If a pod is restarting after a crash, that older instance is often where the useful evidence lives.
Why this matters in CrashLoopBackOff
Crash loops destroy context fast. A container:
- starts
- throws an exception
- exits
- gets restarted
By the time you attach your attention, the active container may be a new attempt with a different lifecycle state, different partial output, or no meaningful logs yet.
Developers then say “there are no logs,” when the real problem is “I am looking at the wrong instance.”
--previous fixes exactly that mistake.
A concrete example
Suppose your Rails or Python container exits instantly because of a bad env var. The docs include an example like:
kubectl logs -p -c ruby web-1That does two valuable things:
- targets the previous container instance
- selects the right container in a multi-container pod
Both details matter. In real pods, confusion often comes from not being explicit enough about which container and which lifecycle instance you want.
The debugging workflow it belongs in
When a pod is unhealthy, this is a better first loop than random guessing:
kubectl describe pod <pod>kubectl logs --previous <pod>kubectl logs <pod>for the current attempt- add
-c <container>if the pod has sidecars
This workflow is more disciplined than jumping between dashboards and hoping the useful lines appear.
Useful flags that combine well with it
The logs docs also call out flags that make the command much more practical:
-cfor container selection--sincefor recent windows--timestampsfor event ordering--prefixto label log lines by pod and container-ffor streaming current logs when the container survives long enough
For example:
kubectl logs --previous -c api my-pod --timestampsThat gives you the terminated container output with timing context, which is often what you need to match against probe failures, deploy events, or dependency outages.
The mistake to avoid
Do not assume --previous is a permanent archive. It is about the previous instance if it still exists. If you delay too long, rotate too much, or rely on it as your entire observability strategy, you will still lose evidence.
That is why serious systems also need centralized logging. But centralized logging does not reduce the value of this flag. It just means kubectl logs --previous is a fast first responder, not the whole incident platform.
Why this saves so much time
This flag is valuable because it matches how container failures actually happen. The crash you care about is often not in the currently running process. It is in the process that just died.
The command turns that obvious-in-hindsight fact into a one-flag habit.
That habit can save fifteen minutes of confused poking every single time a pod restarts before you catch it live.
Final recommendation
When a pod restarts unexpectedly, treat kubectl logs --previous as a default move, not an advanced trick. It is one of the simplest ways to recover the log evidence that Kubernetes restarts otherwise hide from casual debugging.