← Problem Library
K8s L4 K8S 1204 · 17 min

kubectl logs shows the symptom but not the cause because the previous container instance held the real failure

Operators see only the latest restart logs, while the real crash evidence lives in the previous container instance that was replaced during the restart loop.

K8sPlatform ReliabilityLevel 4Pro17 min
Scenario

A restart loop looks mysterious because current logs contain only probe or wrapper noise. The evidence that matters is in the previous instance that operators never inspected.

What to check first
  • Identify the primary failure signal in the Restart Evidence Debug scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Pull crash evidence from the correct container instance before changing resources or probes.

Questions worth viewing together
What should you verify first when kubectl logs shows the symptom but not the cause appears?

Kubernetes debugging problem based on Stack Overflow and Reddit advice about using previous-container logs during restart loops. Restarting pods can erase the most useful evidence unless you check the previous container state quickly.

What usually causes kubectl logs shows the symptom but not the cause in production?

Teams often conclude there is no real log signal when they are just reading the wrong container instance.

What should you document after resolving kubectl logs shows the symptom but not the cause?

Crash loops create log churn fast enough that the useful evidence often lives one restart behind the current pod view.