events -> describe -> logs: the Kubernetes debugging chain (and the --previous flag you're not using)

Almost every Kubernetes debugging session follows the same route. Memorize it: events -> describe -> logs. First see what happened at the cluster level, then the details of a specific Pod, then what the app itself said.

Takeaways

• kubectl logs --previous (-p) is the key to CrashLoopBackOff. The current container just restarted and has written nothing (or crashed again), so plain kubectl logs shows nothing useful. -p pulls the logs of the previous, already-dead instance — that's where the real stack trace lives. Note: -f and -p don't combine (you can't stream something already dead).
• kubectl describe pod → read the Events block bottom-up. Look for Warning with reasons like Failed, BackOff, FailedScheduling. describe tells you what happened at the k8s level ("container crashing, so BackOff"); logs -p tells you why.
• CrashLoopBackOff and ImagePullBackOff are NOT Pod phases. The five real phases are Pending, Running, Succeeded, Failed, Unknown. Those *BackOff strings are display fields kubectl synthesizes from container state — the underlying phase often stays Pending. Confusing the two makes the docs harder to read.
• kubectl get events isn't sorted by time by default — add --sort-by='.lastTimestamp'. Events also have a ~1h TTL, so yesterday's incident is gone.
• Check from inside with port-forward (tunnel via the API server) and exec. No shell (distroless)? Use kubectl debug to attach an ephemeral container.
• k9s is a terminal UI over the same kubectl actions — fast, but understand the commands first.
• Don't over-build. For local dev, logs + describe + events + k9s are enough. A full Prometheus/Grafana/OTel stack is a direction to grow, not a local requirement. Mnemonic: metrics = what, logs = details, traces = why.

Full article: https://dorokhovich.com/blog/local-k8s-debugging-and-observability?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-debugging-and-observability