{"id":74379,"date":"2026-04-26T21:00:00","date_gmt":"2026-04-26T13:00:00","guid":{"rendered":"https:\/\/www.hongkiat.com\/blog\/?p=74379"},"modified":"2026-04-20T18:26:15","modified_gmt":"2026-04-20T10:26:15","slug":"debug-stopped-docker-container","status":"publish","type":"post","link":"https:\/\/www.hongkiat.com\/blog\/debug-stopped-docker-container\/","title":{"rendered":"How to Debug a Stopped Docker Container"},"content":{"rendered":"

Docker containers<\/a> are easy to build and run. But they could also suddenly stop for many reasons. The tricky part often is figuring out why.<\/p>\n

This guide covers practical ways to debug a stopped Docker container, from checking logs and exit codes to preserving its state before you restart anything.<\/p>\n

Check container status and logs<\/h2>\n

When a container stops, your first stop should always be the Docker logs<\/a>. Docker keeps a record of everything that was written to stdout and stderr while the container was running.<\/p>\n

First, let\u2019s see all containers, including stopped ones:<\/p>\n

\r\ndocker ps -a\r\n<\/pre>\n
Look for your container in the list. Note its name or container ID.<\/p>\n
\n        \"docker\n    <\/figure>\n
Then, check its logs:<\/p>\n
\r\ndocker logs [container_name_or_id]\r\n<\/pre>\n
This often reveals the immediate cause. Maybe your application threw an exception, or a dependency failed to start. If the logs don\u2019t show anything obvious, don\u2019t worry. We have more tools.<\/p>\n
Understanding exit codes<\/h3>\n
As you can see from the screenshot above, every Docker container exits with a code. Exit code 0<\/code> means success (the container completed its task). Any other number indicates an error. You can see the exit code in the docker ps -a<\/code> output, or get it directly:<\/p>\n
\r\ndocker inspect [container_name_or_id] --format='{{.State.ExitCode}}'\r\n<\/pre>\n
Common exit codes:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Exit Code<\/th>\nSignal<\/th>\nLikely Cause<\/th>\n<\/tr>\n<\/thead>\n
0<\/td>\nN\/A<\/td>\nSuccess. Container finished task<\/td>\n<\/tr>\n
1<\/td>\nN\/A<\/td>\nGeneral application error<\/td>\n<\/tr>\n
137<\/td>\nSIGKILL (9)<\/td>\nOut-of-memory killer or force stop<\/td>\n<\/tr>\n
143<\/td>\nSIGTERM (15)<\/td>\nGraceful shutdown request<\/td>\n<\/tr>\n
139<\/td>\nSIGSEGV (11)<\/td>\nSegmentation fault (memory access)<\/td>\n<\/tr>\n
255<\/td>\nN\/A<\/td>\nExit status out of range<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If you see exit code 137<\/code>, your container likely hit a memory limit and was killed by the system. Exit code 143 usually means something asked Docker to stop the container gracefully.<\/p>\n
Before you try to bring the container back up, there is one mistake worth avoiding.<\/p>\n
Don\u2019t restart too soon<\/h2>\n
The usual instinct is to run docker start [container]<\/code> or reach for Docker Compose<\/a>. That can erase useful evidence, especially if the container was not configured with persistent storage. You could lose:<\/p>\n