TestForge Blog
← All Posts

Kubernetes CrashLoopBackOff — Complete Fix Guide

Five root causes of CrashLoopBackOff and a step-by-step debugging approach. Essential kubectl commands and real-world resolution examples.

TestForge Team ·

What Is CrashLoopBackOff?

A state where a Pod starts → crashes → restarts in a loop, with increasing wait times.
Kubernetes doubles the backoff interval on each restart, up to a maximum of 5 minutes.

NAME          READY   STATUS             RESTARTS   AGE
my-app-xyz    0/1     CrashLoopBackOff   5          8m

Five Root Causes

1. Application Crash

The most common cause. The app throws an exception or panic immediately on startup.

# Read logs from the already-terminated container
kubectl logs my-app-xyz --previous

# Last 100 lines only
kubectl logs my-app-xyz --previous --tail=100

2. Liveness Probe Failure

The app is running fine, but the probe configuration is too aggressive.

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30   # Too short → probe fires before app is ready
  periodSeconds: 10
  failureThreshold: 3

Fix: Set initialDelaySeconds generously based on actual startup time.

3. OOMKilled (Memory Limit Exceeded)

kubectl describe pod my-app-xyz | grep -A5 "Last State"
# State: Terminated
# Reason: OOMKilled
resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"   # Set above actual peak usage

4. ConfigMap / Secret Mount Failure

The referenced ConfigMap or Secret doesn’t exist.

kubectl describe pod my-app-xyz | grep -A10 "Events"
# Warning  Failed    MountVolume.SetUp failed: secret "db-secret" not found
# Verify Secret exists
kubectl get secret db-secret -n your-namespace

5. Missing Entrypoint Permission

kubectl describe pod my-app-xyz | grep "Error"
# exec /app/start.sh: permission denied

Grant execute permission in your Dockerfile:

COPY start.sh /app/start.sh
RUN chmod +x /app/start.sh

Step-by-Step Debugging Checklist

# 1. Check Pod status
kubectl get pod my-app-xyz -o wide

# 2. Check Events (80% of causes are revealed here)
kubectl describe pod my-app-xyz

# 3. Read previous container logs
kubectl logs my-app-xyz --previous

# 4. Shell into the container (while it's alive)
kubectl exec -it my-app-xyz -- /bin/sh

# 5. Run a debug Pod with the same image
kubectl run debug --image=your-image:tag --restart=Never -- sleep 3600
kubectl exec -it debug -- /bin/sh

Quick Cause Identification

SymptomLikely Cause
Java exception in logsApplication crash
OOMKilledMemory limit exceeded
permission deniedFile execute permission
secret not foundMissing Secret
No logs + probe failureLiveness probe misconfiguration

Automatic Detection with TestForge

TestForge’s Scan feature automatically monitors Pod status after each deploy.
On CrashLoopBackOff, it sends a Slack alert and analyzes the probable root cause — without you having to dig through logs manually.