Uptime Kuma: Erreichbarkeit prüfen, Statusseite, Alarm aufs Telefon

Uptime Kuma ist ein selbst gehosteter Wächter für Erreichbarkeit: Er ruft deine Webseiten, Ports und Dienste regelmäßig auf, schlägt Alarm, wenn etwas nicht antwortet, und zeigt auf Wunsch eine öffentliche Statusseite. Er ersetzt kein Metrik-Monitoring mit CPU- und Speicherkurven, beantwortet aber die wichtigste Frage zuverlässig: Ist es von außen erreichbar? Wie das in ein größeres Monitoring passt, steht in Monitoring, das dich auch nachts erreicht.

Die wichtigste Regel: woanders betreiben#

Ein Wächter auf dem Server, den er bewacht, fällt mit diesem Server aus, und dann meldet niemand etwas. Uptime Kuma gehört auf eine andere Maschine, am besten bei einem anderen Anbieter oder an einem anderen Standort. Ein kleiner VPS reicht dafür.

Aufsetzen mit Compose#

# /srv/uptime-kuma/compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:<hauptversion>
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

Den Tag der aktuellen Hauptversion nimmst du aus der Projektseite auf GitHub. Ein fester Hauptversions-Tag statt latest verhindert, dass ein Update mit Umbauten unbemerkt einspielt.

cd /srv/uptime-kuma
docker compose up -d

Der Port ist bewusst nur an 127.0.0.1 gebunden. Nach außen bringt ihn ein Reverse-Proxy mit TLS. Uptime Kuma nutzt WebSockets; bei Caddy funktioniert das ohne Zusatz, bei nginx brauchst du die Upgrade- und Connection-Kopfzeilen im Proxy-Block.

Beim ersten Aufruf legst du den Administrator an. Mach das sofort nach dem Start: Bis dahin kann jeder, der die Seite erreicht, dieses Konto anlegen.

Die richtigen Prüfarten#

Prüfart	Was sie prüft	Wofür
HTTP(s)	Antwortcode einer URL	Webseiten, APIs
HTTP(s) – Keyword	ob ein Wort in der Antwort steht	Seite liefert 200, aber eine Fehlerseite
TCP-Port	ob ein Port Verbindungen annimmt	Mailserver, Gameserver, Datenbank intern
Ping	ob der Rechner antwortet	Grundprüfung, sagt wenig über Dienste
DNS	ob ein Name richtig auflöst	nach Umzügen, für kritische Domains
Push	ob sich etwas regelmäßig meldet	Sicherungen, Timer, Cronjobs

Keyword schlägt HTTP. Eine Anwendung, deren Datenbank weg ist, liefert oft trotzdem Status 200, mit einer Fehlermeldung im Text. Eine Keyword-Prüfung auf ein Wort, das nur auf der funktionierenden Seite steht, merkt das.

Bei HTTPS-Prüfungen kann Uptime Kuma zusätzlich vor ablaufenden Zertifikaten warnen. Das lohnt sich, auch wenn die Erneuerung automatisch läuft: Genau dann, wenn die Automatik still versagt, kommt die Warnung. Mehr zu kurzlebigen Zertifikaten steht in Zertifikate werden kurzlebig.

Push-Monitore: melden, wenn etwas ausbleibt#

Die unterschätzte Funktion. Ein Push-Monitor wartet darauf, dass sich etwas bei ihm meldet. Bleibt die Meldung aus, gibt es Alarm. Ideal für nächtliche Sicherungen:

# am Ende des Sicherungsskripts, nur bei Erfolg
restic backup /srv && \
  curl -fsS -m 10 "https://status.example.com/api/push/AbCdEf123?status=up&msg=OK" > /dev/null

Den Link zeigt Uptime Kuma beim Anlegen des Monitors an. Als Intervall stellst du etwas mehr als den Abstand der Läufe ein, bei einer täglichen Sicherung etwa 25 Stunden. So erfährst du nicht nur, wenn eine Sicherung fehlschlägt, sondern auch, wenn sie gar nicht erst läuft. Das ist der Fall, den sonst niemand bemerkt. Passend dazu: Restic und systemd-Timer.

Benachrichtigungen#

Uptime Kuma kennt viele Wege: E-Mail, Telegram, Discord, Matrix, ntfy, Pushover und weitere. Zwei Empfehlungen:

Einen Weg, der dein Telefon weckt. Eine E-Mail um drei Uhr nachts liest niemand. Eine Push-Benachrichtigung über ntfy oder Telegram kommt an.
Nicht über den überwachten Server. Läuft dein Mailserver auf dem Server, der ausgefallen ist, kommt die Mail über den Ausfall nie an.

Bei jeder Benachrichtigung gibt es einen Knopf zum Testen. Nutze ihn.

Nicht zu empfindlich#

Ein einzelner Zeitüberlauf ist kein Ausfall. Uptime Kuma kann eine Prüfung wiederholen, bevor es Alarm gibt („Retries“). Zwei bis drei Wiederholungen im Abstand von einer Minute verhindern Alarme wegen kurzer Netzaussetzer. Wer nachts wegen Fehlalarmen geweckt wird, stellt irgendwann alle Alarme ab, und dann auch die echten.

Die Statusseite#

Unter Statusseiten stellst du ausgewählte Monitore öffentlich dar, etwa für Kunden oder Mitspieler eines Gameservers. Sie zeigt den aktuellen Zustand, die Verfügbarkeit der letzten Zeit und von dir geschriebene Vorfallmeldungen. Nimm nur Monitore auf, deren Namen und Adressen öffentlich sein dürfen; interne Hostnamen gehören nicht auf eine Statusseite.

Sichern#

Alle Einstellungen und der Verlauf liegen im Ordner ./data. Er gehört in die normale Sicherung. Vor Updates auf eine neue Hauptversion den Ordner kopieren: Große Versionssprünge stellen die Datenhaltung um, und ein Rückweg ohne Kopie ist schwierig.

Häufige Fragen#

Wie oft soll geprüft werden?#

60 Sekunden sind für die meisten Dienste ein guter Wert. Kürzere Abstände erkennen Ausfälle kaum schneller, erzeugen aber mehr Last und mehr Fehlalarme.

Kann Uptime Kuma auch interne Dienste prüfen?#

Ja, wenn die Maschine sie erreicht, zum Beispiel über WireGuard. So prüfst du auch Datenbanken oder Verwaltungsoberflächen, die bewusst nicht öffentlich sind.

Sehe ich damit, warum etwas ausgefallen ist?#

Nein, nur dass es ausgefallen ist und seit wann. Das Warum steht in den Protokollen des Servers, siehe journalctl.

Was ist mit ungesunden Docker-Containern?#

Uptime Kuma kann den Zustand von Containern abfragen, wenn es Zugriff auf den Docker-Socket bekommt. Das ist faktisch root auf dem Host. Sicherer ist eine HTTP-Prüfung auf den Dienst selbst. Warum Docker ungesunde Container nicht selbst neu startet, steht in Healthchecks und Restart-Regeln.

Kurz gesagt#

Der Wächter läuft auf einer anderen Maschine als das Bewachte.
Keyword-Prüfung statt reiner HTTP-Prüfung, Zertifikatswarnung einschalten.
Push-Monitore melden, wenn eine Sicherung gar nicht erst läuft.
Benachrichtigung aufs Telefon, nicht über den überwachten Server.
Wiederholungen einstellen, sonst werden Alarme wegen Fehlalarmen ignoriert.