Container OOMKilled (exit 137) or stuck in CrashLoopBackOff? How to diagnose the restart loop

A container that won't stay up shows two related but distinct symptoms: exit 137 / OOMKilled (the kernel killed it for using too much memory) and CrashLoopBackOff (Kubernetes restarting a container that keeps crashing). Telling them apart is the first step to fixing either.

Exit 137 / OOMKilled

Exit code 137 is 128 + 9 — the process got SIGKILL. When it's from memory, the container exceeded its cgroup memory limit and the kernel's OOM killer terminated it. It's abrupt: no graceful shutdown, no app-level error.

1. Confirm it's OOM. Check the container's Reason: OOMKilled — 137 can also be a plain SIGKILL from something else.
2. Raise the limit or lower the ceiling. Either give the container more memory, or cap the app to fit: GOMEMLIMIT (Go), --max-old-space-size (Node), -Xmx (JVM).
3. Find the leak. If memory grows unbounded over time, raising the limit only delays the kill — profile and fix the growth.

CrashLoopBackOff

The pod starts, the container crashes, Kubernetes restarts it — with exponentially increasing backoff between attempts. CrashLoopBackOff is the state, not the reason. The container is telling you it can't stay up; it's not telling you why.

Also watch: language-level heap OOM

A JVM or Node process can throw its own heap error (OutOfMemoryError, JavaScript heap out of memory) without a 137 — the runtime hit its own heap limit before the container did. That's a runtime flag (heap size) issue, distinct from the cgroup OOM.

For agents running in containers

An agent whose container gets OOMKilled mid-task just... vanishes, with a restart loop and no diagnosis. diagnose_infra_error returns the container-oom family and distinguishes an OOM kill from a crash loop from a heap error, with the fix for each.