fren
Log In

Monitor VPS uptime

2 min read07 November 2026

A service that answers locally can be unreachable from outside. Availability must therefore be measured from the Internet, not from the machine being watched. The goal is not to collect graphs, but to know within seconds whether the problem is the network, the server or the application.

Choose what to test

Test a URL that proves the application works, not just that Nginx answers. A /health route that checks the database connection is more useful than the home page:

Bash
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 10 https://your-domain.tld/health

For a non-HTTP service (game, database, SSH), test the TCP port. Avoid basing alerts on ping: ICMP is often filtered and says nothing about the application.

Check from outside

A check launched from the VPS cannot detect the VPS being down. Use at least one external point: a monitoring service, another machine, or your phone on mobile data.

Bash
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-domain.tld/
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://your-domain.tld/

If your server is IPv6-only, the IPv4 failure is expected until a dedicated IPv4 is ordered. Note it so you do not mistake that absence for an outage.

Automate with cron

A local script complements external monitoring: it catches an application that runs but no longer answers, and it can log locally.

Text
#!/bin/sh
url="https://your-domain.tld/health"
for i in 1 2 3; do
  code=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 "$url")
  [ "$code" = "200" ] && exit 0
  sleep 30
done
logger -t watch "site down, last code $code"
exit 1

Put it in /usr/local/bin/check-site.sh, make it executable, then call it every five minutes from root's crontab. Three consecutive failures avoid alerts on an Nginx reload.

Tell failures apart

Symptom Likely cause Check
Console works, SSH silent firewall or sshd systemctl status ssh, ss -ltnp
SSH works, HTTP fails Nginx or application journalctl -u nginx, curl localhost
Nothing answers, console works network or firewall ip -6 addr, nft list ruleset
Console unreachable platform or container NeoHeberg support

The dashboard noVNC console remains the best fallback when the container network stops answering.

Reduce false positives

  • Require two or three failures before alerting.
  • Check from a second location before declaring a global outage.
  • Announce maintenance windows and pause alerts during them.
  • Pick an alert channel that does not depend on the monitored server: an alert sent by the failed server will never arrive.
  • Document the recovery procedure so someone else can act.

An external monitoring service remains the foundation: it sees what your users see.

Advertisement

Was this article helpful?

Read next