Skip to content

What do you need to do?

Docs

Monitor a Hetzner VPS

A Hetzner Cloud server is exactly the kind of box the Monitor agent was built for: one box you own, fully under your own control, that the cloud probe fleet cannot see inside of. Install the agent for CPU, memory, disk, and load, add checks for whatever the box exposes, and finish with a status page.

What you are setting up

The Monitor agent on the server itself, a check for each service the box exposes (HTTP, TCP, or both), and a status page. Nothing here is Hetzner-specific beyond "you have root on a Linux box", which is exactly Hetzner Cloud's pitch.

Install the agent

Register an agent from Monitor settings in the dashboard first; the token is shown once, with the exact command below already filled in with it. SSH into the server and run:

bash
curl -fsSL https://realuptime.io/agent/install.sh | sh -s -- --token rua_your_token_here

The script prefers Docker if it is present and usable, and falls back to a hardened systemd service under Node.js 22+ otherwise, which is the common case for a fresh Hetzner image that has not had Docker installed. Confirm it is running:

bash
systemctl status realuptime-agent

See Monitor agent for the Docker Compose form, the cosign signature verification steps, and the full environment variable reference (REALUPTIME_CLUSTER is worth setting if this is one of several Hetzner boxes, so the dashboard groups them).

Create the checks

Anything with a public listener gets its own check: an HTTP check for a web service, a plain TCP check (with optional TLS handshake and certificate-expiry tracking) for anything else, run from the cloud probe fleet rather than the agent itself, since these are checks of reachability from the outside.

bash
export REALUPTIME_API_KEY=ru_live_...

# Public HTTP service on the box
realuptime checks create \
  --name "App on hetzner-01" \
  --url https://app.example.com/ \
  --interval 60 \
  --regions iad,fra,sjc

# A bare TCP port with no HTTP in front of it (Postgres, Redis, SSH)
realuptime checks create \
  --name "Postgres on hetzner-01" \
  --url tcp://203.0.113.10:5432 \
  --interval 60 \
  --regions fra

See TCP checks for certificate-expiry alerts on anything behind TLS, and Checks & monitors for response assertions on the HTTP side.

Add a status page

Create a status page from the dashboard and add the server (via the agent) and each service check as components, so a customer can tell a slow disk from a downed API. See Status pages.

What RealUptime does and does not see

The agent reads /proc, /sys, and /run for CPU, memory, disk, and load; it opens no inbound port and runs nothing RealUptime tells it to run. See Monitor agent, "Outbound only", for the full guarantee. It does not see Hetzner's own hypervisor, network fabric, or billing; for that, Hetzner Cloud Console and Hetzner's own status page are the source of truth.

TCP and HTTP checks see reachability and response from outside the box, over the public internet, the same way a real client would. They cannot tell you why a service is down, only that it is; the agent's server-health data is usually the next thing to check.