Explained
Your app keeps restarting itself — what a restart loop means
Real server problems, translated into plain English by Onserva.
What you're seeing
The dashboard says the app is running — and mostly it is. But users report the site vanishing for a minute at a time, sessions get logged out for no reason, or you glance at the app's uptime and it says three minutes on something you deployed weeks ago. Something keeps killing your app, and something keeps bringing it back.
What it actually means
Container platforms are built to be stubborn: when a configured app dies, the platform starts it automatically. That's usually a virtue — a rare crash at 3am heals itself and nobody notices.
A restart loop is that virtue malfunctioning. The app dies, gets restarted, dies again for the same reason, then gets restarted again — sometimes every few seconds, sometimes every few hours. Because it's technically running most of the time, it can look green. Meanwhile every restart drops whatever it was doing: requests fail, in-memory sessions vanish, and background jobs die halfway through.
The two common families of cause are:
The app is being killed
The machine ran short of memory and chose a victim — this is the OOM kill (out of memory). The executioner is usually not the guilty party: a bloated other container can push the machine into shortage, and your innocent app gets shot for being the biggest thing in the room at the wrong moment.
The app is dying on its own
It crashes on startup — a bad configuration value, a database it cannot reach, or a bug hit immediately — so the restart never gets past the first seconds. These loops are fast and constant rather than occasional.
What to do right now
- Confirm the loop:
docker ps— look at the STATUS column. Restarting, or an uptime of seconds or minutes on an old deploy, confirms it. - Read the app's last words:
docker logs --tail 100 <container>— the lines just before each death almost always name the cause. A crash-on-startup loop shows the same error repeating. - Check whether the kernel executed it:
sudo dmesg -T | grep -i "killed process"— if your app appears here, it was OOM-killed, and this is really a memory problem. Your server has started swapping explains that side. - If it's a startup crash, the log line tells you what to fix — a wrong environment variable and an unreachable database cover many real cases. On Coolify, check the app's environment settings against what the log is complaining about.
The one thing not to do: keep pressing redeploy without reading the logs. If nothing changed, the loop will not either.
When to worry
An app that restarted once this month is a machine doing its job. An app that restarts daily has a slow leak or a nightly pressure spike and deserves a look this week. An app restarting every few minutes is losing you users right now — and if the cause is memory, it's also a warning that any other app on the box could be the next victim.
How Onserva handles this
Onserva watches the memory pressure around a restart loop and shows which containers are using the most memory, without needing Docker's privileged socket. That makes an OOM kill much easier to recognise and investigate.
It does not currently claim to count restarts for each container: the agent does not read Docker's private control socket, deliberately. When the evidence points to a memory problem, a tested restart may be offered for you to authorise; when it points to an application bug, the honest answer is to read the log and fix the app rather than guess.