Docker / Engine, Containers & Runtime Diagnosis
Diagnose Docker exit 137 without assuming every case is OOM
An abrupt kill can come from memory enforcement, an operator or another supervisor. Inspect recorded state before choosing a memory fix.
Environment and inputs: Docker Engine · Compose v2 and Buildx where specified; Linux containers unless noted. Verify daemon context, installed feature support and authorized host or Swarm manager access first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
docker container inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' appRead the result
OOMKilled is runtime evidence where available, while the exit code alone is not a complete causal record. Host or container OOM context may need separate logs.
Resolve and verify
Compare memory limits, host events and application growth at the failure time. Fix the demonstrated leak, concurrency or capacity issue and validate under representative load.
Before changing production
Do not remove all memory limits or conclude a current low-memory snapshot explains the earlier peak.