Capture the previous attempt
CrashLoopBackOff describes repeated failed starts with a backoff between attempts; it is not the underlying cause. Inspect the Pod's status, events, container name and last termination reason. Where a previous container instance exists, retrieve its logs:
kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME --previous
Logs can contain secrets or customer data, so share only a sanitized excerpt. If the process exits before logging, inspect the image command, arguments and configuration.
Separate application and platform signals
An application may exit because of invalid configuration, a missing secret, incompatible image architecture or an unavailable dependency. A container can also be terminated after a failed liveness probe or because of a memory limit. Verify the recorded reason and events; do not infer an out-of-memory kill solely from a restart count.
Review startup, readiness and liveness probes against the application's actual startup behavior. A readiness failure stops traffic to an instance but is not identical to a liveness-triggered restart. Probe changes should reflect a measured startup contract, not conceal a failing service.
Reproduce and verify
Test the same image and configuration in a safe environment. Change one suspected cause, roll out a controlled revision and confirm the container remains healthy, becomes Ready and serves a representative request. Monitor restart counts and dependency errors after release.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.