previous terminated container not found: There is no earlier container instance whose logs can be read

kubectl logs --previous only works when a previous container exists on the node. If the pod was recreated rather than restarted, or the node cleaned up, the logs are gone.

Applies to: All Kubernetes versions

What it means

The kubelet keeps the logs of a container's previous instance on the node so that --previous can retrieve them after a restart. This depends on two things being true: the restart happened in place on the same pod, and the node has not cleaned up the old container. Deleting and recreating a pod does not preserve anything, because the new pod is a different object on a possibly different node. Log rotation and container garbage collection also remove old logs over time. So the logs of a crash that happened yesterday are usually irretrievable, which is an argument for shipping logs off the node rather than relying on the kubelet's retention.

Most common causes

• The pod was deleted and recreated rather than the container restarting in place.
• The container has not restarted yet, so there is no previous instance.
• Container garbage collection removed the old container from the node.
• Log rotation discarded the file.
• The pod moved to a different node, leaving the old logs on the original one.
• The wrong container was named in a multi-container pod.

How to diagnose it

1. Check the restart count: kubectl get pod POD. Zero restarts means there is nothing previous by definition.
2. Check the pod's age against when the failure happened — a pod younger than the incident is a different pod.
3. Name the container explicitly in a multi-container pod: kubectl logs POD -c CONTAINER --previous.
4. Check whether a log aggregation system holds the output, which is the only reliable source after the fact.

How to fix it

1. Ship logs to an aggregation system. Node-local retention is best-effort and will not survive rescheduling.
2. Capture logs immediately when a crash loop is observed, before the pod is deleted or rescheduled.
3. Avoid deleting a failing pod before reading its logs — the instinct to recreate it destroys the evidence.
4. Tune kubelet log rotation settings if slightly longer local retention would help, understanding it is still not durable.

Notes

Deleting a crash-looping pod is the most common way its logs are lost. The pod is recreated, the loop starts fresh, and the original failure — which may have differed from subsequent ones — is unrecoverable.

Related

• container is waiting to start — The container never started, so it has no logs
• CrashLoopBackOff — Repeated restarts with increasing delay

Sources

• Kubernetes documentation — kubectl logs
• Kubernetes documentation — Logging Architecture
• Kubernetes documentation — Debug Running Pods