Skip to content
Knowledge base

External uptime monitoring for a Hetzner server (SysMon is not enough)

Hetzner's own tools watch your server from inside Hetzner: console graphs, and SysMon's checks for dedicated boxes, all observe from the provider's own network. What they structurally cannot tell you, and how to add the outside half: probes from independent regions, an agent for the box's own health, and a status page.

1. Know what provider-side monitoring can and cannot see

Hetzner's Cloud console graphs CPU and traffic, and dedicated servers get SysMon's basic checks with email alerts. Both observe from inside Hetzner's own network, and that is the structural limit, not a quality complaint: a probe next door to the server cannot tell you whether users in another part of the world can reach it, and it shares fate with the very network it is watching. A routing or DNS problem between your users and Hetzner is invisible from inside Hetzner, and it is exactly the outage your users experience.

2. Probe from regions that share nothing with the box

Create an HTTP check for each web service on the server and a TCP check for anything else it exposes (Postgres, Redis, SSH, mail). Checks run from RealUptime's own probe fleet across ten regions (US-East, US-West, Europe, Asia-Pacific, US-Central, Canada, UK, Southeast Asia, Australia, and South America), with each selected region reporting separately, so "unreachable from everywhere" and "unreachable from one continent" read as the different problems they are.

3. Install the agent for the inside half

Outside probes answer "does it respond"; the Monitor agent on the box answers "how much room is left". One command installs it (Docker if present, a hardened systemd service otherwise) and it reports CPU, memory, disk, and load with thresholds you set, so a disk filling up pages you before it takes the service down. The agent is outbound-only and runs nothing RealUptime sends.

4. Track certificates and cron jobs while you are here

TCP checks with TLS enabled track certificate expiry and alert ahead of it, which retires a whole category of self-inflicted outage. Anything the box runs on a schedule (backups especially) gets a heartbeat monitor: the job pings after it succeeds, and silence is what alerts, catching the crontab entry that quietly stopped running.

5. Finish with a status page and real alerting

Put the server and its service checks on a status page so "is it down" gets a measured public answer, and route alerts to email, Slack, webhook, or your existing paging tool, with escalation policies on paid plans deciding who is woken when the first person does not answer. An email from a provider-side check is a notification; this is an alerting workflow.

Go deeper

The full reference lives in the docs: Monitor a Hetzner VPS documentation. Error codes named above are each explained in the error-code reference.