Opyntel

Exit code 137 on Coolify: why your container was killed, and how to get warned

Coolify exit code 137 means the kernel killed your application, nearly always for memory. Coolify runs each application as a Docker container on your server. By default it sets no memory limit, so a container can grow until the whole server runs out. For the general picture, see exit code 137 and OOM killed.

What you see

The application shows as exited or restarting, and its restart count goes up. The runtime logs stop mid-line, because a killed process cannot write a last message. If another container on the same server died at the same time, the server ran out of memory and the kernel picked one, and it may not be the container that grew.

Confirm it on the server

SSH into the server and run:

bash
docker inspect <container> --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
journalctl -k | grep -i "killed process"
free -h

true 137 means an OOM kill. The kernel log says which kind: Memory cgroup out of memory means the container hit its own limit, while a plain Out of memory: Killed process line means the whole server ran short. false 137 with no such line means a plain SIGKILL, such as a stop that timed out.

How to fix it

  1. Set a memory limit per application. In the application’s Resource limits settings, set Memory limit (0 means no limit). A limit keeps one leaking app from taking the database and Coolify itself down with it.
  2. Leave room for the server. The limits of all containers, plus Coolify, the proxy and your databases, should fit in the server’s RAM.
  3. Add swap as a cushion, not a fix. It buys time on a small VPS, but a leak still fills it.
  4. Cap the runtime. For Node, set --max-old-space-size to about 75 percent of the container’s limit.
  5. Move the database to its own server once the apps outgrow the box.

What Coolify warns you about

Coolify notifies on deployments, resource status changes (a container stopping unexpectedly), restart-limit events, server reachability and disk usage, to email, Discord, Telegram, Slack, Pushover or a webhook. In practice, users report no notification when a container is killed or crashes. Sentinel draws CPU and memory charts once metrics are on, but it has no memory thresholds.

How Opyntel warns you first

Opyntel reads your Coolify instance through its API and Sentinel. It measures each container’s memory against its limit when you set one. Without a limit, it measures the server’s memory against its RAM, which is what the kernel acts on. It alerts when memory passes your threshold. Restarts appear on one activity timeline next to deploys, with an alert when a service goes down, by email, Slack or SMS depending on your plan.

Sentinel metrics must be on for each server, on its Charts page. Without them, Opyntel still shows states, deploys and restarts, but no memory.

Coolify monitoring in Opyntel
FAQ

Coolify exit code 137 questions, answered

Restarts, shared servers and Docker Compose apps.

Yes, under Docker’s restart policy, until the restart limit is reached. Coolify notifies you when the restart limit is reached, not on each kill.

With no memory limits, the kernel kills the process with the highest OOM score on the whole server. A large database is often that process.

Coolify has no Sentinel metrics for Docker Compose applications or one-click services. Set mem_limit in the Compose file, and watch the server’s memory.

The alerts your platform doesn’t send.

One dashboard for everything you run, with the alerts your platforms leave out. Read-only, nothing to install in your apps.

See how it works