Kubernetes / Pods, Containers & Application Health
Diagnose CrashLoopBackOff from the previous container attempt
Backoff describes Kubernetes delaying repeated starts, not the application's underlying error. Capture the failed container's last available output.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl -n app logs pod/web-0 -c web --previous --tail=100
Read the result
The command requests retained logs from the previous terminated instance of the named container. No previous log can reflect rotation, runtime behavior or a different container target.
Resolve and verify
Compare the first application error with termination state, configuration and dependencies. Repair the cause in the managed workload and verify restart count stabilizes.
Before changing production
Do not delete the Pod as a routine fix or blindly increase restart tolerance. Logs can contain private data.