---
title: "Hetzner server monitoring with Telegram alerts | Logdash"
description: "What Hetzner Cloud graphs, Robot SysMon and load balancer health checks cover, what they miss, and an outside HTTP check that alerts you on Telegram."
url: https://logdash.io/monitor/hetzner
---

# Hetzner server monitoring

Hetzner Cloud draws CPU, disk and network graphs for every server but sends no alert when one stops answering, so you add an outside HTTP check against a health path on the server or load balancer and route its alert to Telegram.

Hetzner servers are cheap, and the monitoring matches the price. The Cloud Console graphs CPU, disk IOPS and network traffic for every server, measured from the hypervisor. That is enough to spot a runaway process. It cannot see inside the guest, so a full disk, an OOM-killed Postgres or nginx answering 502 to every visitor all look normal on those graphs while CPU sits at 12%. And the graphs never message anyone: there is no threshold alert in the Console.

## Hetzner cloud monitoring: what you get

- Cloud servers: CPU, disk and network graphs in the Console and through the metrics API. No memory graph, no disk usage, no alerts.
- Dedicated servers in Robot: System Monitor (SysMon), free ping, port and HTTP checks. Email only, and it alerts on the second consecutive failure, not the first. Its HTTP check accepts only 200, 301 and 302.
- Load balancers: active health checks over HTTP, HTTPS or TCP, every 15 seconds by default with 3 retries. An unhealthy target is pulled from rotation and nobody is told.

## Hetzner load balancer health check

If you run a load balancer, its health check is already watching. The catch is the default: the root path, and any 2xx or 3xx counts as healthy. That passes as long as the web server answers, even when the app behind it cannot reach its database. Point it at a real health path, expect exactly 200, and keep the timeout well under the interval.

 hcloud CLI 

```bash
# Check /health on the app port instead of /
hcloud load-balancer update-service my-lb \
  --listen-port 443 \
  --health-check-protocol http \
  --health-check-port 3000 \
  --health-check-http-path /health \
  --health-check-http-status-codes 200 \
  --health-check-interval 15s \
  --health-check-timeout 5s \
  --health-check-retries 3

# Which targets does it call healthy right now?
hcloud load-balancer describe my-lb

# What a user gets through the load balancer
curl -sS -o /dev/null -w '%{http_code} in %{time_total}s\n' \
  https://example.com/health
```

That check protects users from one bad target. It does nothing when every target is bad, which on a one or two server setup is the usual outage: the load balancer has nowhere to send traffic, every request fails, and Hetzner sends no notification.

## Hetzner VPS monitoring from outside

An outside HTTP monitor asks the question your users ask, through the same DNS, TLS and load balancer. Logdash sends a GET every 5 minutes on the free plan, every minute on Builder at $9 a month and every 15 seconds on Pro at $15, records the status code and response time, and alerts on the first failed check. Anything outside 200-399, a refused connection or no answer within 10 seconds counts as down. It only calls public addresses, so a private network IP like 10.0.0.2 is rejected: point it at the load balancer or the server's public hostname.

1. **Add the URL** Create a service in Logdash and paste https://example.com/health, the same path the load balancer checks. The first check runs straight away, so a wrong path shows up now.
2. **Connect Telegram** Add a Telegram channel once and attach it to the monitor. A webhook works the same way if you route alerts through your own handler.
3. **Break it on purpose** Stop the app on every target. The next check fails, the monitor flips to down and a Telegram alert lands with the monitor name, the status code and the error. Start the app again and a second message says it is back up.

### Logdash vs Hetzner built-in monitoring

| Feature                                   | Logdash                                       | Hetzner                                          |
| ----------------------------------------- | --------------------------------------------- | ------------------------------------------------ |
| Alert when a Cloud server stops answering | Telegram or webhook on the first failed check | None, graphs only                                |
| Dedicated server checks                   | HTTP only                                     | SysMon: ping, port, HTTP, DNS and mail protocols |
| Alert channels                            | Telegram and webhook                          | Email, from SysMon only                          |
| Removes a broken server from traffic      | No, it only watches                           | Load balancer drops failing targets              |
| Cost                                      | Free for 5 services at 5-minute checks        | Included with the server                         |

### When Hetzner built-in tools is the better pick

- You run dedicated servers and email is enough. SysMon is free, already in Robot, and checks ping and ports, which Logdash does not.
- You only need traffic to avoid one broken server. The load balancer health check does that every 15 seconds with no outside tool.
- You need memory and disk usage alerts. Neither Logdash nor the Console sees inside the guest, so run node\_exporter with Prometheus for those.

### Does Hetzner server monitoring send alerts? 

Only for dedicated servers. SysMon in Robot emails you after the second consecutive failed ping, port or HTTP check. Hetzner Cloud servers get graphs and nothing that contacts you, so an outside monitor is the only way to hear about a Cloud server going down.

### What is the simplest Hetzner VPS monitoring setup? 

A health path in your app, one HTTP monitor pointed at it from outside Hetzner, and a Telegram channel. On the Logdash free plan that covers 5 services at a 5-minute interval. Add node\_exporter later if you want memory and disk graphs.

### What does Hetzner Cloud monitoring show? 

CPU usage, disk IOPS and throughput, and network traffic, measured from the hypervisor and also available through the metrics API. Memory and disk space are not shown, because the host cannot see inside your server.

### How do I configure a Hetzner load balancer health check? 

Set the service health check to HTTP on the port your app listens on, with path /health and status code 200\. The defaults are a 15-second interval, a 10-second timeout and 3 retries. The hcloud load-balancer update-service command above sets all of it in one call.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[DigitalOcean droplet monitoring](https://logdash.io/monitor/digitalocean): DigitalOcean already covers droplet monitoring with free resource alerts once you install its metrics agent and Uptime checks at $1 a month each after the first, so an outside monitor earns its place only for Telegram or webhook alerts, sub-minute checks, or a status page.

[VPS monitoring](https://logdash.io/monitor/vps): VPS monitoring means an outside check that alerts you when the server stops answering, plus a heartbeat from inside that stops when the disk fills or the app dies, because most provider dashboards give you graphs rather than alerts.

[Homelab monitoring](https://logdash.io/monitor/homelab): Homelab monitoring needs two layers, detailed checks inside the lab, usually Uptime Kuma, and one watcher outside it, because a monitor that shares your power, router and internet line goes silent exactly when those fail.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.