Kubernetes

How to Debug Kubernetes CrashLoopBackOff

Find why a Kubernetes container repeatedly crashes by checking pod events, previous logs, exit codes, probes, configuration, and resource limits.

Updated 2026-07-122 min read

CrashLoopBackOff means a container repeatedly starts, exits, and is restarted with an increasing delay. Kubernetes is reporting the restart behavior; the exit reason is usually in the container state, previous logs, events, or probe configuration.

Describe the pod

kubectl describe pod POD -n NAMESPACE

Inspect Last State, exit code, restart count, conditions, and recent events. If the pod has multiple containers, identify the one that is restarting.

Read logs from the previous container

The current container may be too new to contain the failure:

kubectl logs POD -n NAMESPACE -c CONTAINER --previous
kubectl logs POD -n NAMESPACE -c CONTAINER --tail=200

Do not publish logs without checking them for credentials, tokens, customer data, or connection strings.

Interpret common exit reasons

OOMKilled or exit code 137: inspect memory usage and limits.
Exit code 1: read the application’s first meaningful error.
Exit code 126 or 127: verify command, image, and executable permissions.
Successful exit code 0: the workload may be a job incorrectly managed as a Deployment.

Check probes and configuration

kubectl get pod POD -n NAMESPACE -o yaml
kubectl get events -n NAMESPACE --sort-by=.lastTimestamp

Check command, args, environment sources, mounted ConfigMaps and Secrets, working directory, and liveness/startup probes. A liveness probe can restart an application that simply needs more startup time.

Diagnose it with Rumus

AI-native terminal Commands require your approval

Why use Rumus for this diagnosis?

Rumus is an AI-native terminal that can use your current Kubernetes context to correlate pods, events, logs, controllers, resources, and nodes. It keeps the investigation read-only until you approve a proposed change.

What Rumus can inspect

Pods, events, previous logs, and owning controllers
Resources, probes, scheduling rules, and node state
Secret-aware output and approval before cluster changes

Download Rumus

Diagnose this CrashLoopBackOff in namespace NAMESPACE. Inspect pod state, previous
container logs, events, exit reason, resource limits, probes, command, and mounted
configuration. Redact Secret values. Start read-only and do not restart, delete,
scale, or edit the workload without approval.

Confirm the fix

After changing the owning Deployment, StatefulSet, or other controller:

kubectl rollout status deployment/NAME -n NAMESPACE
kubectl get pods -n NAMESPACE -w

Confirm that restart counts remain stable and that the application passes its real health checks.

Diagnose the real environment

Open the server in Rumus and let the AI agent inspect context, propose a plan, and ask before it runs changes.