CrashLoopBackOff ☸️ Kubernetes

Kubernetes: CrashLoopBackOff

The container starts, crashes (or exits), and Kubernetes keeps restarting it with increasing back-off delays.

Seen on: Kubernetes Docker

Meaning

CrashLoopBackOff is a symptom, not a cause. The real error is in the previous container’s logs or in the pod’s events/last state (exit code, OOMKilled, failed probes).

Common causes

  • Application error on startup (missing env var, config, secret)
  • Container command exits immediately (no long-running process)
  • Liveness probe failing and killing the container
  • OOMKilled due to low memory limit
  • Can’t reach a dependency (DB) and exits
  • Wrong image/entrypoint for the architecture

⚡ Quick fix

  1. kubectl logs <pod> --previous to see why it crashed
  2. kubectl describe pod <pod> → Last State, Exit Code, Events
  3. Check env vars, ConfigMaps and Secrets are mounted
  4. Relax/repair liveness probes (initialDelaySeconds)

Detailed fix by platform

Kubernetes

  1. Investigation commands:
    bash
    kubectl get pods
kubectl describe pod api-7d9f8b6c5-x2kqp
kubectl logs api-7d9f8b6c5-x2kqp --previous
kubectl get events --sort-by=.lastTimestamp | tail -20
  2. Exit code 137 = killed (often OOM), 1 = app error, 127 = command not found, 126 = not executable.

How to diagnose

  1. Previous logs — What did the app print before dying?
  2. Exit code — From describe → Last State
  3. Probes — Liveness killing it?
  4. Resources — OOMKilled?
  5. Config — Env/secrets present?

🧠 Still stuck? Analyze your error

Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.