stern never sets the Previous flag on its log requests, so it can only show the currently running instance - the crash you are debugging is invisible to it. For the dead instance, use kubectl logs --previous [pod]. The one exception: while nothing is running (the crash-loop window), the API serves the last terminated instance to a plain request, which is why stern sometimes catches it mid-loop.

## The error
```text
(no error - stern tails the current instance only, so the crashed instance's logs never appear)
```

## What to do
1. Get the crashed instance's logs directly:
```bash
kubectl logs [pod] -n [namespace] --previous
```
   Expected: Prints the dead container's output.
2. If the pod already restarted again, target the crash window: run stern while the container is down.
   Expected: stern shows the terminated instance's tail during the gap.
3. For the full picture, combine: --previous for the crash, stern for the live tail.
   Expected: Both sides of the restart covered.

## When this applies
- debugging CrashLoopBackOff with stern
- stern showing fresh-start logs but not the crash
- post-restart forensics

## When it does NOT apply
- stern returning forbidden errors (RBAC)
- pods that never started (nothing logged yet)

## Works with
stern 1.x; kubectl for the --previous side

### kubectl logs --previous says previous terminated container not found
The kubelet already garbage-collected it. Check the log backend or node retention.

## Why it happens
The Kubernetes log API has a previous-instance flag that kubectl exposes as --previous. stern's request builder does not set it, so the API always answers with the current instance.

## Edge cases
- Init container crashes have the same gap - kubectl logs --previous -c [init-container].
- Logs older than node retention are gone from the API entirely; query the centralized log backend instead.

## Resolved from
gh:shyuan/skills (stern-logs recipes) - https://github.com/shyuan/skills/blob/HEAD/skills/stern-logs/references/recipes.md