Inspect runtime failures

A container stops when its main process exits. Restarting blindly can hide the evidence that explains why it exited.

Start with ps -a, inspect the exit code, and read logs. Use stats for live resource pressure and exec only while the container is running. Keep application logs on standard output and standard error so the runtime can collect them.

docker ps -a
docker inspect notes --format "{{.State.ExitCode}} {{.State.Error}}"
docker logs --tail 100 notes
docker stats --no-stream notes
docker exec -it notes sh

Container state gives stronger clues than the word “crashed.” Inspect whether the process was killed for memory pressure, how many times a restart policy retried it, and the timestamps around the exit:

docker inspect notes --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}'

An exit code points to the process result, while .State.Error can reveal a runtime failure before the process started, such as a missing executable. Connectivity failures usually appear after startup and should be tested from the same network namespace. Preserve the failing container until you have captured evidence, change one variable, and rerun the smallest command that can disprove your current hypothesis.

Start the API with an intentionally invalid command, diagnose the exit, then restore the correct command.