How to fix Container exited with code 137 (OOMKilled) in Docker

DockerINTERMEDIATEHIGHUpdated Dec 1, 2025· 279 views

Exit code 137 indicates your Docker container was forcibly terminated by the system's out-of-memory (OOM) killer. This occurs when a container exceeds its allocated memory limit or the host system runs out of available memory.

Quick fix

Fixes 137

docker inspect -f '{{.State.OOMKilled}}' <container_id>
  1. Verify OOM was the cause
  2. Monitor current memory usage
  3. Increase memory limit when running container
  4. Increase Docker Desktop memory (Mac/Windows only)
docker — error
docker inspect -f '{{.State.OOMKilled}}' <container_id>
Container exited with code 137 (OOMKilled)

What this error means

Exit code 137 means your container received a SIGKILL signal (signal 9) and was terminated immediately. In Unix/Linux systems, when a process exits due to a signal, the exit code equals 128 plus the signal number, so 128 + 9 = 137. This exit code most commonly appears when the Linux kernel's OOM (Out of Memory) killer terminates your container because it consumed too much memory. The kernel prioritizes system stability over individual processes, so when memory runs critically low, it will kill memory-hungry processes to prevent system-wide crashes. Docker's daemon is configured with a higher OOM priority, making individual containers more likely to be killed than the Docker daemon itself. When you see "OOMKilled: true" in docker inspect output alongside exit code 137, you know the memory limit was the culprit.

Typical symptoms

  • Container exits unexpectedly with exit code 137
  • Docker inspect shows 'OOMKilled': true
  • Application crashes during memory-intensive operations
  • Container restarts repeatedly in Kubernetes or Docker Compose
  • Host system logs show 'Out of memory: Kill process' messages
  • Docker stats shows memory usage hitting 100% before crash

Common causes

  1. Container exceeded its configured memory limit (--memory flag)
  2. Host system ran out of available RAM and swap space
  3. Application has a memory leak that gradually consumes all available memory
  4. Workload requires more memory than allocated (undersized limits)
  5. Multiple containers competing for limited host memory resources
  6. Docker Desktop on Mac/Windows has insufficient VM memory allocated
  7. Container was manually killed with 'docker kill' or 'docker stop' after timeout

How to fix "Container exited with code 137 (OOMKilled)"

1Verify OOM was the cause

First, confirm that memory was actually the issue by inspecting the container:

bash
docker inspect -f '{{.State.OOMKilled}}' <container_id>

If this returns true, the OOM killer was responsible. Also check the exit code:

bash
docker inspect -f '{{.State.ExitCode}}' <container_id>

You can also check system logs for OOM events:

bash
# On systemd systems
journalctl -k | grep -i "killed process"

# Or check dmesg
dmesg | grep -i "out of memory"
2Monitor current memory usage

Before making changes, understand your container's actual memory needs:

bash
# Real-time memory stats for all containers
docker stats

# For a specific container
docker stats <container_name>

Watch the MEM USAGE and LIMIT columns. If usage consistently approaches the limit, you need to increase allocation.

3Increase memory limit when running container

Set an appropriate memory limit using the --memory flag:

bash
# Allocate 1GB of memory
docker run --memory=1g --name myapp myapp:latest

# Combine with memory-swap to prevent swap usage
docker run --memory=1g --memory-swap=1g --name myapp myapp:latest

For Docker Compose, add resource limits to your service:

yaml
services:
  myapp:
    image: myapp:latest
    deploy:
      resources:
        limits:
          memory: 1G
        reservations:
          memory: 512M
4Increase Docker Desktop memory (Mac/Windows only)

On macOS and Windows, Docker runs in a VM with limited memory allocation:

Docker Desktop:
1. Open Docker Desktop
2. Go to Settings/Preferences
3. Select Resources → Advanced
4. Increase the Memory slider (e.g., from 2GB to 4GB or more)
5. Click "Apply & Restart"

This is often the quickest fix if you're developing locally and see exit code 137.

5Investigate and fix memory leaks

If increasing limits only temporarily fixes the issue, your application likely has a memory leak:

For Node.js applications:

bash
# Generate heap snapshots
node --inspect app.js

Use Chrome DevTools to analyze memory over time.

For Java applications:

bash
# Enable JVM memory profiling
docker run --memory=1g \
  -e JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps" \
  myapp:latest

For Python applications:

bash
# Use memory_profiler
pip install memory_profiler
python -m memory_profiler app.py

Common leak sources: unclosed database connections, circular references, unbounded caches, and accumulating event listeners.

6Optimize application memory usage

Reduce memory footprint through code optimization:

- Process data in streams/chunks rather than loading entire datasets
- Implement proper connection pooling with max limits
- Use pagination for large database queries
- Clear unused objects and close file handles
- Implement LRU caches with size limits
- Avoid keeping large objects in memory unnecessarily

Example for Node.js streams:

javascript
// Bad: loads entire file into memory
const data = fs.readFileSync('large-file.txt');

// Good: processes in chunks
fs.createReadStream('large-file.txt')
  .pipe(processStream)
  .pipe(fs.createWriteStream('output.txt'));

Advanced notes

Understanding "Invisible" OOM Kills: In Kubernetes, if the OOM killer selects a process other than PID 1 inside your container, the container won't be marked as OOMKilled and won't restart. Only when the init process (PID 1) is killed does Kubernetes detect the OOM event. Monitor kernel logs (dmesg) to catch these invisible kills.

The --oom-kill-disable Flag: You can disable the OOM killer for a container with --oom-kill-disable, but this is dangerous. Only use it in combination with --memory limits, otherwise the container can freeze the host system. Note that this flag is not supported on cgroups v2.

Memory Swap Behavior: The --memory-swap flag controls how much swap space a container can use. Setting it equal to --memory disables swap entirely for that container. While swap can prevent OOM kills, it severely degrades performance. It's better to allocate sufficient RAM than rely on swap.

Exit Code 137 Without OOM: Exit code 137 can also occur if you run docker stop and your application doesn't handle SIGTERM gracefully within the 10-second timeout. Docker sends SIGTERM, waits, then sends SIGKILL (resulting in exit 137). To diagnose this, check if OOMKilled is false in docker inspect.

Host-Level Memory Pressure: Even if your container is under its limit, the host's overall memory pressure can trigger the OOM killer. Use docker system df and free -h to check host resources. Consider distributing containers across multiple hosts or upgrading host memory.

Frequently asked questions

What does "137" mean?
Exit code 137 means your container received a SIGKILL signal (signal 9) and was terminated immediately. In Unix/Linux systems, when a process exits due to a signal, the exit code equals 128 plus the signal number, so 128 + 9 = 137. This exit code most commonly appears when the Linux kernel's OOM (Out of Memory) killer terminates your container because it consumed too much memory.
How do I fix "137"?
Exit code 137 indicates your Docker container was forcibly terminated by the system's out-of-memory (OOM) killer. This occurs when a container exceeds its allocated memory limit or the host system runs out of available memory.
What causes "137"?
Container exceeded its configured memory limit (--memory flag) Host system ran out of available RAM and swap space Application has a memory leak that gradually consumes all available memory
Is the "137" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading