The container keeps restarting. Is it running out of memory?

Capture the state while the context is still available

Run docker inspect --format '{{.Id}} {{json .State}}' web, replacing web with the container name. Record OOMKilled, ExitCode, StartedAt and FinishedAt together with its ID. OOMKilled concerns the period since the last start; it is not an archive of every earlier failure. Save the output with the observation time and compare it with a specific service failure.

Exit code 137 alone does not prove OOM. It can involve SIGKILL after someone manually terminates a process or uses docker kill. Check deployments and administrative actions in the timeline too. Raising a limit based only on a number in the output changes configuration without an established cause. First identify which run of the container you are investigating.

Connect Docker events with kernel messages

In docker events, look for oom, die and start events for the relevant ID. The --since and --until options bound the period; include a time zone in timestamps. Event history is limited, so collect important records continuously. A missing old record does not by itself disprove an event. Compare times with the failed request rather than just the container's current state.

On a host using systemd, use journalctl -k to view kernel messages. This selects the current boot by default; after a host restart, choose the correct boot and time window. For an OOM record, compare the process, time and reported context with the affected container. If records are unavailable or access is restricted, keep the cause unconfirmed and add collection for the next occurrence.

Compare the container limit and the host's condition

Docker can limit memory through --memory. Free host RAM therefore does not establish that the container's limit is sufficient. In its correct cgroup v2, compare memory.max and memory.current: the hard limit and current usage including descendants. In memory.events.local, oom_kill counts group processes killed by an OOM killer. That alone does not distinguish a local shortage from a system-wide one; revisit kernel messages too.

For a current overview, use docker stats --no-stream web. On Linux, this output subtracts part of the cache, so its figure need not match the raw memory controller value. Collect the trend before an incident and label the metric's source. A single sample after recovery cannot explain an earlier peak. Use the same measurement when comparing results before and after a change.

Verify the repair with the work that was failing

In a separate environment, reproduce the relevant data volume and concurrency. Investigate whether a smaller batch, less concurrency or a change to application memory management helps. Rising usage warrants profiling; it is not automatic proof of a leak. If the limit needs raising, first assess host capacity and the other services. Do not disable OOM protection as a substitute for diagnosis.

A restart policy can start the container again, but it does not remove the cause of termination. After the repair, monitor recurring failures, the memory trend and the original operation's outcome. Combine external availability checks with internal memory and restart data. Confirm that file processing also completes under comparable load, rather than treating a running process as sufficient evidence of repair.

• Capture the container ID, state and time of the affected run.
• Compare Docker events with kernel messages.
• Check the limit, usage trend and host capacity.
• Repeat the original operation and watch for further failures.