Explained
Your site is slow after a deploy — what that actually means
Real server problems, translated into plain English by Onserva.
What you're seeing
You shipped a change, and now everything drags. Pages that answered in half a second take two. Sometimes it settles after ten minutes; sometimes it doesn't, and you start wondering whether your change broke something — usually while refreshing the page you just deployed.
What it actually means
A deploy is usually the heaviest thing your server does all day. If your platform builds on the same machine that serves your sites — which is how Coolify and most self-hosted setups work out of the box — then for a few minutes your production server is also a build server: compiling, bundling, and writing gigabytes of layers to disk.
That burst has an aftermath. The build's hunger for memory evicts the things that made your site fast: the database's cached pages, the files the operating system kept in memory, sometimes whole chunks of your apps pushed out to slower disk. When the dust settles, everything still works — it is just working from cold. Speed comes back as the caches refill, which is why the slowness fades on its own.
The restart itself adds its share: the new version of your app starts with empty caches and unprimed connections, and its first visitors pay for that warm-up.
Why it happens
- The build runs on the production box. Compiling and bundling can briefly demand more processor and memory than your apps use all day, and every other tenant of the machine feels it.
- Caches start cold. The build's memory burst evicted them; the restart emptied the app's own. The first minutes after a deploy are the slowest your site will be all week.
- Memory got parked on disk. If the burst pushed the machine into swapping, pieces of your running apps now live on the slow disk and get fetched back on demand — a drag that outlasts the deploy by a while.
- The machine is simply too full. A box that is comfortable serving traffic can still be too small to serve traffic and build at the same time.
What to do right now
Usually: wait ten minutes before concluding anything. Cold caches refill themselves, and most post-deploy slowness is exactly that. While you wait:
- Check whether the machine is still digesting:
free -h— if swap use grew during the deploy, the drag will fade as things page back in. - Confirm it's everything, not your change: if other sites on the box are slow too, the machine is the story, not your code.
- If it recurs on every deploy, that is the machine telling you builds don't fit any more. The clean fixes are moving builds off the box (a separate build server, or building images in CI and pulling them) or giving the machine more headroom.
When to worry
Worry when the slowness has not faded half an hour after the deploy finished — that is no longer warm-up. Worry if response times step up and stay up after a particular release: that is your change, and the deploy just delivered it. And if apps start dying and restarting after deploys, the machine is genuinely out of memory — that is a separate problem: your server ran out of memory.
How Onserva handles this
We watched exactly this on one of our own production servers through a week of heavy deploying. Rather than a wall of graphs, this is the kind of thing it sends:
Pages are still being served without errors, but responses have slowed from roughly a third of a second to about one second. Alongside this there is unusually heavy writing to the disk, so something on the machine is likely working hard and holding memory. Nothing needs to be stopped or restarted at the moment.
That's the product: watched every twenty seconds, explained in English, and honest about what needs a person versus what will settle by itself.