DEV Community

overnight.host
overnight.host

Posted on

How to monitor your VPS on a budget — uptime, resources and alerts

#vps #devops #monitoring #selfhosting

The cheapest way to find out your server is down is for a user to tell you. Don't be that operator. Monitoring a VPS well costs nothing but an afternoon, and it turns "why didn't anyone notice for six hours" into a push notification before most people refresh the page. Here's a practical, free stack.

Three things worth watching

  1. Is it up? Reachability from outside your own network.
  2. Is it healthy? CPU, RAM, disk — the slow leaks that take a box down at 4 a.m.
  3. Did something break? Failed services, full disks, errors in logs.

You can cover all three without paying for an enterprise APM.

1. External uptime checks

The single most important monitor lives off your server, because a check running on a dead box can't alert you. Free options like Uptime Kuma (self-hosted on a second machine) or a hosted free tier ping your URL every minute and notify you on failure.

If you self-host Uptime Kuma, run it somewhere other than the server it watches — a second cheap VPS in a different region, or a Raspberry Pi at home. Point it at your real user-facing URL, not just the IP, so you catch TLS and DNS failures too.

A nice habit: publish your uptime on a public status page. It keeps you honest and answers the "is it just me?" question without a support ticket.

2. Resource monitoring

For a single box, htop and df -h over SSH go a long way, but you want history, not just a snapshot. A lightweight, genuinely free option is netdata:

wget -qO- https://my-netdata.io/kickstart.sh | sh
Enter fullscreen mode Exit fullscreen mode

It gives you per-second CPU, memory, disk I/O, and network graphs in a local web UI with essentially no configuration. Bind it to localhost and reach it through an SSH tunnel rather than exposing the dashboard to the internet:

ssh -L 19999:localhost:19999 root@your-server
Enter fullscreen mode Exit fullscreen mode

Then open http://localhost:19999.

3. Service and disk alerts

The two failures that bite small servers most often are a service that died silently and a disk that filled up. Catch both with a tiny cron script:

#!/usr/bin/env bash
# /usr/local/bin/healthcheck.sh
DISK=$(df / | awk 'END{print +$5}')
if [ "$DISK" -gt 85 ]; then
  echo "Disk at ${DISK}% on $(hostname)" | mail -s "DISK WARNING" you@example.com
fi
systemctl is-active --quiet nginx || \
  echo "nginx down on $(hostname)" | mail -s "SERVICE DOWN" you@example.com
Enter fullscreen mode Exit fullscreen mode 
chmod +x /usr/local/bin/healthcheck.sh
# run every 5 minutes
echo "*/5 * * * * root /usr/local/bin/healthcheck.sh" | sudo tee /etc/cron.d/healthcheck
Enter fullscreen mode Exit fullscreen mode

No mail server set up? Pipe the alert to a push service like ntfy instead — a one-line curl to a private topic lands on your phone.

Don't over-alert

The fastest way to start ignoring alerts is to get fifty a day. Alert on things that need a human: down, nearly-full, service crashed. Let graphs handle the rest — you look at those when you're investigating, not when you're asleep.

Closing note

Good monitoring is mostly about putting the check in the right place (outside the box) and not crying wolf. If you'd rather not babysit it, every plan at overnight.host backs a 99.9% uptime SLA with live, public numbers you can check yourself — same philosophy, just one less thing for you to run, in whichever region you choose.

Top comments (0)