Skip to content
Onserva

Explained

Your server has started swapping — what that actually means

Real server problems, translated into plain English by Onserva.

What you're seeing

Your monitoring shows swap usage climbing. Or nobody told you anything — the sites have just gone strangely slow, pages take seconds instead of milliseconds, and SSH feels like typing through treacle. Both are the same problem wearing different clothes.

What it actually means

Your server has two kinds of storage: fast memory (RAM), which is small, and the disk, which is big but hundreds of times slower. Everything running on the machine wants to live in fast memory.

When the machine runs short of fast memory, it doesn't crash. It quietly picks the data it has used least recently and parks it on the disk instead. That parking space is called swap. The machine is making a sensible trade: better to be slow than to be dead.

The trouble is what happens next. If something needs that parked data, the machine has to fetch it back from the slow disk — and park something else to make room. When memory stays tight, it ends up doing this constantly, shuffling data back and forth instead of doing useful work. That shuffle is why everything feels slow at once: it isn't one app struggling, it's the whole machine spending its time moving furniture.

Why it happens

On a server running containers — a Coolify box being the classic case — it's rarely one villain. It's the total:

  • Every container keeps what it was given. An app that needed a lot of memory during a busy moment often holds on to it afterwards.
  • Builds and deploys ask for big bursts. Compiling and bundling can briefly demand more memory than the apps themselves use all day.
  • Memory use creeps. Some apps slowly grow forever — a small leak that takes weeks to matter.
  • The machine was sized for launch day, and you've added two more apps since.

What to do right now

Nothing urgent, in most cases. A server using some swap is normal. A server whose swap use is climbing needs attention within days, not minutes.

  1. See the overall picture: free -h — compare available memory against total, and note swap used.
  2. Find who's holding the memory: docker stats --no-stream — look for the container whose memory is far above what the app plausibly needs.
  3. If one container is bloated, restarting just that app returns its memory and usually restores speed within a minute. On Coolify, restart it from the dashboard.
  4. If everything is genuinely in use and nothing is bloated, the honest answer is that the machine is too small for what it now runs. Upgrade the RAM or move an app off.

When to worry

Worry when swap use climbs steadily over hours, when the machine's available memory sits near zero constantly, or when you see apps being killed and restarting on their own — that's the machine running out entirely and choosing victims. That last one is a separate problem: your app keeps restarting itself, not merely swapping.

How Onserva handles this

Onserva watched exactly this happen on one of our own production servers.

Coolify has begun shifting some of its working data onto the disk because it ran short of fast memory, and the amount moved there has grown from about a fifth to just over a quarter in the last hour. No urgent action is needed, but this is worth keeping an eye on over the next day or two. If the amount parked keeps climbing, a restart of the applications would return the server to a clean state.

That's the product: an agent reads the server every twenty seconds, while Onserva checks your sites from outside it every minute. When there is a problem, it explains what happened in English and offers a tested fix for you to authorise where one fits.