Container Stopped Suddenly? Understanding Docker Exit Code 137

Introduction

Few things are more frustrating than logging into a server and discovering that a critical container has unexpectedly stopped.

You run:

docker ps -a

and see something like:

CONTAINER ID   IMAGE          STATUS
b7f4fb65d83b   mysql:latest   Exited (137)

The application was working perfectly yesterday. There are no obvious errors in the application logs, and users are now reporting service interruptions.

So what happened?

Docker Exit Code 137 is one of the most common container termination codes, but it is often misunderstood. While many engineers immediately assume the application crashed, the actual cause is frequently external to the application itself.

In this article, we’ll explore what Exit Code 137 means, common causes, troubleshooting steps, and how to prevent unexpected container shutdowns.

What Does Exit Code 137 Mean?

Docker Exit Code 137 indicates that the main process inside the container received a SIGKILL (Signal 9).

Linux calculates exit codes for signals using:

128 + Signal Number

For example:

128 + 9 = 137

Therefore:

Exited (137)

means the process was forcibly terminated.

Unlike a normal application shutdown, a SIGKILL cannot be ignored or handled. The process stops immediately.

Common Causes of Exit Code 137

There isn’t a single cause for Exit Code 137.

Several situations can trigger it.

1. System Memory Exhaustion

One of the most common reasons is memory exhaustion.

When a Linux server runs out of available memory, the operating system may terminate processes to protect overall system stability.

In containerized environments, this often appears as:

Exited (137)

even though the application itself never crashed.

2. Container Memory Limits

Containers can be configured with memory limits.

Example:

docker run --memory=1g myapp

If the container attempts to use more memory than allowed, it may be terminated.

3. Manual Termination

A user or automation tool may forcefully stop the container using:

docker kill container-name

or

kill -9 <pid>

Both actions result in a SIGKILL signal.

4. Host-Level Resource Pressure

Even when a container appears healthy, the host machine may be under heavy resource pressure.

Memory-intensive workloads running elsewhere on the server can indirectly impact containers.

First Steps When Troubleshooting Exit Code 137

When you encounter Exit Code 137, avoid immediately blaming the application.

Start with a systematic investigation.

Check Container Status

docker ps -a

Example:

CONTAINER ID   IMAGE          STATUS
b7f4fb65d83b   mysql:latest   Exited (137)

This confirms the container was terminated with SIGKILL.

Check Container Logs

docker logs <container-name>

Look for:

• Memory errors
• Unexpected shutdown messages
• Application crashes
• Resource warnings

Sometimes the logs reveal the root cause immediately.

Inspect Container Details

docker inspect <container-name>

Check for:

"OOMKilled": true

If this value is true, the container was terminated because of memory pressure.

Investigating Server Memory

One of the first things I check during an Exit Code 137 investigation is server memory usage.

Check Available Memory

free -h

Example:

               total   used   free
Mem:            4Gi    3.9Gi  50Mi
Swap:           0B      0B     0B

A server operating with almost no free memory is a warning sign.

Monitor Running Processes

htop

or

top

These tools help identify processes consuming excessive RAM.

Monitor Containers

docker stats

Example:

CONTAINER      MEM USAGE / LIMIT
mysql-db       500MiB / 1GiB
web-server     1.1GiB / 1.5GiB

Containers consistently approaching their limits deserve attention.

Checking System Logs

Kernel logs often provide the most valuable information.

Review:

dmesg | grep -i kill

or

journalctl -k

Look for messages indicating that Linux terminated a process.

These entries often reveal exactly which process was affected and why.

Understanding Exit Codes Related to Signals

Exit Code 137 is not the only signal-related exit code you may encounter.

Examples:

Exited (130)

Application interrupted manually.

Exited (143)

Application received a graceful shutdown request.

Exited (137)

Application was forcefully terminated.

Understanding these codes can significantly speed up troubleshooting.

Preventing Unexpected Container Shutdowns

Add Swap Space

Swap provides additional virtual memory when RAM becomes exhausted.

Verify current swap:

swapon --show

If no swap exists, consider adding it.

Monitor Resource Usage

Implement monitoring tools such as:

• Grafana
• Prometheus
• Netdata
• Datadog

Continuous monitoring helps identify problems before they impact production.

Configure Restart Policies

Restart policies help containers recover automatically.

docker update --restart unless-stopped my-container

Available options:

For production environments, unless-stopped is often the preferred option.

Review Resource Allocation

Regularly evaluate:

• Available server RAM
• Container limits
• Application memory requirements
• Traffic growth

Infrastructure that was sufficient six months ago may no longer be adequate today.

A Practical Troubleshooting Checklist

When you encounter Exit Code 137:

1. Check container status.
2. Review application logs.
3. Run docker inspect.
4. Check memory usage with free -h.
5. Monitor processes using htop.
6. Review docker stats.
7. Inspect kernel logs.
8. Verify restart policies.
9. Confirm resource limits.
10. Monitor for recurring patterns.

Following this process helps identify the root cause quickly and consistently.

Conclusion

Docker Exit Code 137 doesn’t necessarily mean your application crashed.

It simply indicates that the container’s main process received a SIGKILL signal and was terminated. The challenge is determining why that signal was sent.

By checking container logs, inspecting memory usage, reviewing system logs, and monitoring resource consumption, you can quickly identify the underlying cause and prevent future interruptions.

The next time you see:

Exited (137)

don’t assume the application failed.

Treat it as a clue and begin investigating what happened outside the application itself.