Select Page

How to prevent Docker containers from crashing with error 137

How to prevent Docker containers from crashing with error 137

Docker systems can be used for a wide range of applications, from setting up development environments to hosting web instances.

Live Docker containers that crash often can end up ruining their purpose. As a result, a major concern faced by Docker providers is ensuring the container uptime.

Containers crash due to many reasons, the main issue being lack of enough memory. During a crash, container will show an exit code that explains the reason for its crash.

Docker containers crashing often?



Today we’ll see what causes Docker ‘Exited (137)’ crash message and how to fix it.

What causes error 137 in Docker

Docker crashes are often denoted by the message ‘Exited’ in the container ‘STATUS’ when listing the container using ‘docker ps -a’ command.

Error 137 in Docker denotes that the container was ‘KILL’ed by ‘oom-killer’ (Out of Memory). This happens when there isn’t enough memory in the container for running the process.

‘OOM killer’ is a proactive process that jumps in to save the system when its memory level goes too low, by killing the resource-abusive processes to free up memory for the system.

Here is a snippet that shows that the Mysql container Exited with error 137:


Docker container exited with error 137

Docker container exited with error 137


When the MySQL process running in the container exceeded its memory usage, OOM-killer killed the container and it exited with code 137.

[ Running a Docker infrastructure doesn’t have to be hard, or costly. Get world class Docker management services at affordable pricing. ]

How to debug error 137 in Docker

Each Docker container has a log file associated with it. These log files store all the relevant information and updates related to that container.

Examining the container log file is vital in troubleshooting its crash. Details of the crash can be identified by checking the container logs using ‘docker logs’ command.

For the MySQL container that crashed, the log files showed the following information:


Docker error 137 - Out of memory

Docker error 137 – Out of memory


The logs in this case clearly shows that the MySQL container was killed due to the mysqld process taking up too much memory.

Reasons for ‘Out of memory’ error 137 in Docker

In Docker architecture, the containers are hosted in a single physical machine. Error 137 in Docker usually happens due to 2 main out-of-memory reasons:

1. Docker container has run out of memory

By default, Docker containers use the available memory in the host machine. To prevent a single container from abusing the host resources, we set memory limits per container.

But if the memory usage by the processes in the container exceeds this memory limit set for the container, the OOM-killer would kill the application and the container crashes.

An application can use up too much memory due to improper configuration, service not optimized, high traffic or usage or resource abuse by users.

Docker system architecture

Docker system architecture

Looking for a stable Docker setup?

Talk to our Docker specialists today to know how we can keep your containers top notch!


1 Comment

  1. I ran into a similar error when deploying to AWS ECS, but it was not related to memory usage of mysql.
    It turned out that the containers started with my docker-compose config isn’t connected by a default network when deploying to ECS, and when referring to the db service for example, the reference will fail and my app would fail talking to the db.
    Though unclear why, this seems to be the reason causing my db instance to crash with 137 because as soon as I add back the legacy “links” options to interconnect the containers, it stopped crashing.


Submit a Comment

Your email address will not be published. Required fields are marked *

Bobcares is a server management company that helps businesses deliver uninterrupted and secure online services. Our engineers manage close to 51,500 servers that include virtualized servers, cloud infrastructure, physical server clusters, and more.