Fixing CrashLoopBackOff

CrashLoopBackOff means a container started, exited, and Kubernetes is now waiting longer and longer between restart attempts. It's a symptom, not a cause — the job is to find why the container exits.

Triage checklist

1. Read the logs. Open the pod and stream its logs. The crash reason is usually in the last few lines before it died. Check the previous container instance, not just the current one.
2. Check the exit code. In the pod's container status: 1 is a generic app error, 137 is OOM-killed (out of memory), 139 is a segfault.
3. Look at events. The pod's events often show image pull errors, failed mounts, or failing probes.
4. Review probes. An aggressive livenessProbe can kill a container that's simply slow to start. Loosen initialDelaySeconds or use a startupProbe.
5. Confirm config. Missing or wrong environment variables, ConfigMaps, or Secrets are a frequent cause. Verify the referenced objects exist in the same namespace.
6. Check resources. Exit code 137 means the container exceeded its memory limit. Raise the limit or fix the leak.

In Kubexer

• The pod drawer surfaces status, the restart count, recent events, and a one-click logs stream.
• Use Resource Edit in the Workbench to adjust probes or resource limits and re-apply without leaving the app.