VPS monitoring
Monitoring for VPS fleets across providers: one dashboard for hosts that have no shared network, on instances too small to afford a heavy agent.
Last updated 2026-08-26
A VPS fleet has two properties that break most monitoring setups. The instances are small - a 1 GB box cannot spare a hundred megabytes for a monitoring stack - and they are scattered across providers with no shared private network, so anything that assumes a flat internal network does not apply.
Small instances
The agent is a single static binary that takes one snapshot per tick and schedules its expensive collectors on long intervals. There is no runtime to install, no per-metric process spawning, and nothing to tune before it is safe to run on a 1 GB instance.
Because uptime, TLS and ping probes run on the panel, adding availability monitoring to a VPS costs that VPS nothing - which matters most exactly on the machines that can least afford it.
Scattered across providers
Each agent connects outbound over TLS to the panel. There is no inbound port to open, no VPN to build, and no firewall exception on the instance. A box at one provider, a box at another and a box in a colocation rack all appear on the same page without any of them being able to reach each other.
What is worth watching on a VPS
- Disk, first and always. Small volumes fill fast and a full disk is the most common VPS outage.
- Memory and swap. A 1 GB instance with no swap dies silently to the OOM killer; the metric that predicts it is sustained memory pressure, not the crash.
- Steal time, which tells you the problem is the host and not your instance - the one metric that turns an argument with a provider into a fact.
- SSH brute force, because a public VPS is scanned continuously from the moment it exists.
- Uptime and TLS certificates, probed from the panel, for whatever the instance serves.
The Free plan covers one server forever without a card, which is usually enough to decide whether the rest is worth paying for.