Guide

How to monitor a Vultr server

A VPS comes with root access, full control — and nobody watching your app. That last part is the one that bites.

Published · Updated

When you rent a VPS, you also quietly take over a job your old shared host did for you: noticing when the site is down. Vultr monitors what it's responsible for — the physical host, the hypervisor, the network — and its console will happily show your instance as Running while nginx is crashed, your app is throwing 500s, or the disk is full. Nothing in that stack is Vultr's to watch; it's yours. The fix is to monitor the thing you actually care about, from the place your users are: an external HTTP check against your site's URL, one that runs from outside the box — because a watcher running on the server dies with the server.

What Vultr watches — and what “Running” really means

Vultr's responsibility ends where your operating system begins. The platform keeps the physical hardware healthy, the hypervisor up, and the network routed; the console graphs show CPU, bandwidth and disk activity. All useful — and all about the machine. “Running” means the virtual machine is powered on. It does not mean a web server is listening, a certificate is valid, or a single page loads. Between “the VM is on” and “the site works” sits your entire stack, and no one at Vultr is looking at it.

Everything that can die while the console stays green

  • The web server crashes — nginx or Apache segfaults, gets OOM-killed, or fails to come back after a config change. Visitors get connection refused; the console shows a healthy, mostly idle VM.
  • Your app process dies — the Node/Python/PHP process behind the proxy exits, and every request becomes a 502.
  • The database stops — pages that need it return 500s while static ones still load, the most deceptive half-outage there is.
  • The disk fills up — logs grow until writes fail; databases and web servers start failing in strange ways long before the machine itself looks unhealthy.
  • The SSL certificate expires — an auto-renew cron that stopped working months ago finally matters, and browsers wall your site off behind a security warning.
  • A reboot doesn't bring everything back — kernel updates or host maintenance restart the VM, and services without restart policies simply stay down.

Why monitoring from the same box lies to you

The tempting move is a script on the server — a cron job that curls localhost and emails you if it fails. It has a fatal flaw: it shares fate with the thing it watches. If the server hangs, loses network, fills its disk or gets rebooted into a broken state, your watcher is down at exactly the same moment your site is — silence, precisely when you needed the alarm. The absence of alerts stops meaning “all is well” and starts meaning “all is well, or everything is so broken the alarm can't fire.”

A localhost check also tests the wrong path. It skips DNS, the firewall, and TLS — the outside half of your stack. Only a check from outside the box travels the road your users travel, and only a check that survives your server's death can tell you about it. That's the honest argument for external monitoring, and it's the same reason a quick outside probe is the first thing to run when you suspect trouble.

Basics on the box that pair well with it

External monitoring tells you something broke; these make breakage rarer and recovery automatic:

  • Restart policies — Restart=always in your systemd units (or restart: unless-stopped for Docker containers), so a crashed process gets picked back up in seconds and a reboot brings the whole stack back.
  • Disk headroom — logrotate configured, and a habit of keeping the disk under ~80%. Full disks cause the weirdest outages on small VPSes.
  • Certificate auto-renewal you've actually tested — run your renewal (e.g. certbot renew --dry-run) once to prove the cron does what you think.

The setup, concretely

Create one monitor for the site your server serves — the real URL, checked every few minutes from outside. When something breaks, the symptom tells you where to look: connection refused means the box is up but the service is down (SSH in, restart it); a timeout means the box or network is gone (check the Vultr console, reboot from there). PingStuff emails you the moment an outage is confirmed, with that distinction already made in plain English, by email or text to a verified Canadian mobile. If it's host-side, this guide's templates will get you a useful answer from support faster.