Server monitoring & management
Server monitoring built for Docker hosts.
Your containers are the easy part. It’s the machine underneath — the disk quietly filling with layers, the memory pressure building — that takes sites down. Onserva watches the host and every container on it, and explains problems in plain English, without ever touching the Docker socket.
Built and run in the UK by No Fear Tech Ltd. Watching production Docker hosts today.
docker ps says everything is up. That is not the same as everything being fine.
A compose stack fails from underneath. The disk fills with image layers until a deploy dies mid-pull. A container leaks until the out-of-memory killer starts choosing victims — and the restart policy hides the evidence. The host swaps, and every site gets slow at once while every status says “Up”.
So most people still find out one of three ways: a deploy fails, a customer emails, or the whole box stops answering. All three are too late.
Onserva watches from outside the server, around the clock, and tells you before any of those happen.
What Onserva watches on a Docker host
Per-container memory and processor
Which container is holding the memory, straight from the operating system’s own accounting — without the agent ever touching the Docker socket. The socket is root; a monitoring tool has no business holding it.
Disk filling up
Image layers, build cache, volumes and logs grow until a pull fails with "no space left on device". We forecast from the trend weeks out — and clearing dangling layers is a one-press, pre-tested action, never a 3am prune typed by hand.
Memory pressure and swapping
Containers ask for memory in bursts, and a limit-hit container can thrash swap while the host looks half-empty. We watch the machine’s real behaviour — the trend, not the spike.
Restart loops
A container that keeps dying and being brought back shows as "Up 30 seconds" forever. We show the memory pressure and load around it, so an out-of-memory loop is much easier to spot.
Your sites, from the outside
"The container is running" and "the site answers" are different facts. We check your sites the way a visitor reaches them, with certificates and domain expiry watched on the same clock.
Silence
Onserva runs somewhere else. A machine that dies cannot switch off its own alarm — silence is itself something we tell you about, within a couple of minutes.
What an alert actually looks like
Docker host
The server 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.
Why: something on the server asked for a lot of memory at once recently, and rather than run out, the machine parked the least-used data on disk. The readings cannot show which of the three applications caused it.
What to do: 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.
A real message from one of our own production Docker hosts. Not a mock-up.
How it works
Four steps, and only one of them is yours.
- 1
Paste one command
It installs a small agent that reads what Linux already publishes about itself. It does not touch the Docker socket, your containers, or your compose files. No dependencies, no reboot.
- 2
We watch, every twenty seconds
The machine, its containers, its databases, its sites — judged on sustained trends.
- 3
You get told what and why
A message on Telegram or by email within a minute, in words you can act on.
- 4
You press Authorise
Where a known, tested fix applies — clearing dangling image layers, restarting a struggling service — one button does it and tells you what happened. Where none does, we say so plainly rather than guessing.
The agent only ever makes outbound connections — no port is opened, and the Docker socket is never touched. The AI can read your readings and suggest actions from a short, pre-tested list; it is never given the keys. Every fix waits for you, every time. How this is enforced, in detail
Questions Docker hosts’ owners actually ask
Why is Docker using so much disk space?
Almost always three things: image layers nothing references any more (every build and pull leaves some behind), build cache, and container logs that were never given a size limit. The dangerous folk remedy is running prune commands with --all at 3am and hoping. Onserva shows you the trend before it is urgent, and its one-press clean-up clears only machine-rebuildable clutter — dangling layers, never a named image, a volume, or anything a container is using.
How do I monitor Docker containers without Prometheus and Grafana?
You can absolutely build the classic stack — Prometheus, Grafana, cAdvisor, an alertmanager, and an evening of YAML. You will get powerful dashboards you then have to interpret yourself. Onserva is the other trade: one pasted command, per-container memory and processor figures out of the box, and alerts that arrive as explanations rather than chart lines. Keep Grafana if you love it — on the Fleet plan, Onserva's readings are scrapeable in Prometheus format too, so the two can share one source of truth.
Why does my Docker container keep restarting?
The most common cause is memory: the container hits its limit (or the host runs short), Linux kills the biggest process inside it, and the restart policy brings it straight back — looking "Up 10 seconds" all day. The log line to look for is the out-of-memory killer, and the tell in the readings is memory pressure climbing just before each restart. Onserva shows that pattern plainly, and says honestly when the cause is an application bug a restart cannot fix.
Is it safe to give a monitoring agent the Docker socket?
Treat the Docker socket as root, because it is: anything holding it can start a privileged container and own the machine. Onserva’s agent NEVER touches the socket — per-container figures come from the operating system’s own process accounting, which is world-readable. That is a deliberately smaller set of numbers than the socket would give, and we think that is the right trade for something that runs on machines we do not own.
Do I need to open a port or give you SSH access?
No port is ever opened; the agent only makes outbound connections. Fixes you authorise are carried out through the agent’s outbound channel, from a short, pre-tested list — never by anyone signing in to your machine.
Stop finding out from a failed deploy.
Your first server is monitored free, forever. One command, two minutes, nothing to configure.