VPS monitoring
VPS monitoring means an outside check that alerts you when the server stops answering, plus a heartbeat from inside that stops when the disk fills or the app dies, because most provider dashboards give you graphs rather than alerts.
Start with what the provider already gives you. Hetzner Cloud shows CPU, network and disk IO graphs in its console and sends no alerts. DigitalOcean has a free metrics agent with threshold alerts, and uptime checks at $1 a month each after the first. Most others sit between the two. A resource graph cannot tell you that nginx answers 502 to every visitor, because the box itself looks idle.
Two failures matter on a single VPS. The fast one: the server or the app stops answering from outside, after a kernel panic, the OOM killer, a bad deploy or a provider network fault. The slow one: logs fill the disk until Postgres refuses writes. The first needs a check from somewhere else. The second needs something on the box.
VPS uptime monitoring from outside
Put an HTTP monitor on a public URL of your app, ideally a health route that runs one database query. The Logdash free plan covers five services checked every 5 minutes, Builder checks every minute for $9 a month, Pro every 15 seconds for $15. Every check records the status code and response time. Anything outside 200 to 399, or no answer within 10 seconds, counts as down.
A heartbeat from inside the box
#!/bin/sh
# Pings Logdash only while the disk has room and the app answers locally.
# Cron starts it once a minute; it pings six times, 10 seconds apart,
# because a Pro push monitor expects a ping in every 15-second window.
PING_URL="https://api.logdash.io/ping/YOUR_MONITOR_ID"
APP_URL="http://127.0.0.1:3000/health"
for i in 1 2 3 4 5 6; do
used=$(df --output=pcent / | tail -n 1 | tr -dc '0-9')
if [ "$used" -lt 90 ] && curl -fsS -m 2 -o /dev/null "$APP_URL"; then
curl -fsS -m 2 -o /dev/null -X POST "$PING_URL"
fi
sleep 10
done
# chmod +x /usr/local/bin/vps-heartbeat, then crontab -e:
# * * * * * /usr/local/bin/vps-heartbeatPush monitors are a Pro feature. The script folds two checks into one signal: when the root disk passes 90% or the app stops answering on localhost, the pings stop and the monitor goes down. Add a memory or load check the same way. The df flags are GNU, so this runs as is on Debian and Ubuntu. One missed 15-second window is an alert, so a short network blip shows up as a down and up pair. That is the cost of hearing about real problems within 30 seconds.
VPS monitoring tool for the box itself
Graphs of CPU, memory and disk over time are an agent job: Netdata, Beszel, or the provider agent on DigitalOcean. Logdash does not install one. Keep the agent for diagnosis and the outside check for the alert, because an agent on a box that has stopped cannot report its own death unless something outside expects to hear from it.
- Watch it from outside Create a service in Logdash and point an HTTP monitor at https://yourapp.com/health. This part runs on the free plan.
- Add the heartbeat On Pro, create a push monitor, put its id in the script, make it executable and add the crontab line. The monitor turns green within a minute.
- Trip the threshold Change 90 to 1 in the script so the disk check fails. The pings stop, the push monitor goes down within 30 seconds, and a Telegram alert lands saying no call was received for this time range.
Logdash vs Uptime Kuma
| Feature | Logdash | Uptime Kuma |
|---|---|---|
| Where the checker runs | Hosted, outside your server | A server you run, ideally not the one it watches |
| Free tier | Five HTTP monitors every 5 minutes | As many monitors as the box can handle |
| Heartbeats from the box | Pro only, $15 a month | Push monitors included |
| Disk, memory and CPU | No agent, you script the threshold into the heartbeat | Not collected either |
| Monitor types | HTTP and push | HTTP, TCP, ping, DNS, keyword and more |
| Maintenance | Nothing to update | Container updates, backups and its own uptime |
When Uptime Kuma is the better pick
- You already pay for a second server at a different provider. Kuma on that box watches the first one for free.
- You need TCP or ping checks on things that do not speak HTTP, such as SSH or a game server.
- You want dozens of monitors and are happy to own the box they run on.