Job Support Bridge

DevOps guide

Kubernetes CrashLoopBackOff: find the cause before changing the deployment

A practical diagnostic sequence: inspect the container state, read the previous logs, and distinguish application failures from probe and resource issues.

CrashLoopBackOff describes Kubernetes delaying repeated container restarts. It does not identify the underlying application failure. The useful question is: why did this particular container stop?

1. Identify the failing container

Confirm the cluster context and namespace first. In a Pod with several containers, investigate the container that is restarting rather than treating the entire Pod as one process.

kubectl get pods -n NAMESPACE
kubectl describe pod POD -n NAMESPACE

Read the restart count, current state, last termination reason, exit code, and Events. These signals help distinguish an application exit from a resource-related termination or a failed health check. Replace the uppercase placeholders with your own resource names.

2. Read the logs from the failed instance

kubectl logs POD -n NAMESPACE -c CONTAINER
kubectl logs POD -n NAMESPACE -c CONTAINER --previous

The previous-instance logs can contain the failure that disappears when a new container starts. Look for the earliest meaningful error rather than only the last line. Log availability depends on your cluster and container history.

3. Check the configuration against the evidence

Compare the startup command, required configuration, mounts, dependency addresses, and resource settings with what the application expects. If the failure began after a rollout, compare the relevant change with the last working version. An OOMKilled reason warrants checking memory behavior and limits; it is not proof that increasing the limit is the right permanent fix.

4. Understand which probe is failing

A failing readiness probe affects whether the Pod receives service traffic. Failing startup or liveness probes can cause a restart. Check the configured path, port, timeout, and actual startup behavior. Disabling a probe can hide the symptom while leaving the original problem unresolved.

A useful next step: write down one hypothesis supported by the Events and logs, reproduce it in a development environment, and test the smallest relevant correction. Verify both application readiness and restart behavior afterwards.

What to bring to a support session

A redacted description of the failure, relevant Events, the failing container's previous logs, and the change immediately before the issue. Leave out Secret values, customer information, and access credentials.

Official references

Published 31 October 2026. Check changes against your own environment and your team’s process.