- Uptime Kuma ist ein kostenloses, quelloffenes Programm, das du selbst betreibst. Es prüft im festen Takt, ob deine Dienste antworten, und schlägt Alarm, wenn einer nicht mehr erreichbar ist.
- Es kennt rund 30 Prüf-Arten (Webseite, Netzwerk-Port, Ping, Zertifikatsablauf, Docker-Container …) und über 90 Benachrichtigungswege wie Telegram, Discord, E-Mail, ntfy oder Gotify.
- Wichtigster Grundsatz: Der Wächter darf nicht auf demselben Server oder an derselben Internetleitung hängen wie die überwachten Dienste — sonst fällt er im Ernstfall mit aus.
- Version 2.0 ist seit Oktober 2025 stabil. Für Umsteiger zentral: Der JSON-Export als Backup ist weg, gesichert wird nur noch das Datenverzeichnis.
Ein Dienst im Heimnetz fällt selten mit Ansage aus. Die Foto-Sammlung lädt nicht mehr, das Backup läuft seit drei Nächten ins Leere, das Verschlüsselungs-Zertifikat der eigenen Cloud ist abgelaufen — und gemerkt hat man es erst, als jemand nachgefragt hat. Genau diese Lücke schließt Uptime Kuma: ein kleines Programm, das rund um die Uhr nachsieht, ob deine Dienste noch da sind, und dir Bescheid gibt, bevor es andere tun.
Was Uptime Kuma ist — und was nicht
Uptime Kuma ist freie Software unter der MIT-Lizenz, seit Juli 2021 entwickelt vom Einzelentwickler Louis Lam aus Hongkong. Das Projekt liegt 2026 bei rund 90.000 Sternen auf GitHub (einer Plattform, auf der Entwickler ihren Code teilen) und wird aktiv gepflegt, finanziert über Spenden. Technisch ist es ein einzelner Node.js-Prozess — Node.js ist eine Laufzeitumgebung, mit der JavaScript-Programme außerhalb des Browsers laufen. Im Leerlauf braucht Kuma grob 80 MB Arbeitsspeicher und läuft schon auf einem Raspberry Pi 3 flüssig. Üblich ist die Installation als Docker-Container (eine abgekapselte Programm-Umgebung) auf Port 3001, mit einem festen Ordner für das Datenverzeichnis.
Wichtig zur Einordnung: Kuma misst Erreichbarkeit und Antwortzeit — nicht CPU-Last, Arbeitsspeicher, Temperatur oder Plattenfüllstand. Für echte Ressourcen-Werte sind Werkzeuge wie Prometheus mit Grafana, Netdata, Beszel oder Glances zuständig. Kuma ist die Ergänzung dazu, kein Ersatz — es kann seine Daten sogar per /metrics an Prometheus weiterreichen.
Wie das Überwachen funktioniert
Kuma legt für jeden Dienst einen „Monitor“ an und fragt ihn im eingestellten Intervall aktiv ab. Es gibt rund 30 Monitor-Typen. Die wichtigsten für den Anfang:
- HTTP(S): Ruft eine Webadresse auf und prüft, ob eine gültige Antwort kommt.
- HTTP-Keyword: Prüft zusätzlich, ob ein bestimmtes Wort im Seiteninhalt steht — nützlich, wenn eine Fehlerseite formal noch „OK“ meldet.
- TCP-Port: Testet, ob ein Netzwerk-Port offen ist, etwa bei einem Datenbank- oder SSH-Dienst.
- Ping/ICMP: Der einfache „Antwortet dieser Rechner überhaupt?“-Test.
- DNS-Record: Prüft, ob ein Namenseintrag noch aufgelöst wird.
- TLS-Zertifikat: Warnt rechtzeitig, bevor ein Verschlüsselungs-Zertifikat abläuft.
- Docker-Container: Fragt direkt beim Docker-Dienst nach, ob ein Container läuft.
Dazu kommen Spezialfälle wie WebSocket, MQTT, gRPC, RADIUS, Steam-Gameserver, Datenbank-Pings und — seit Version 2.5 — NTP für Zeitserver.
Der Push-Monitor: ein Totmannschalter
Ein Typ arbeitet andersherum. Beim Push-Monitor fragt nicht Kuma den Dienst ab, sondern ein Skript oder ein Cronjob (eine zeitgesteuerte Aufgabe) ruft in festem Takt eine Kuma-Adresse auf und meldet „ich lebe“. Bleibt dieser Ruf aus — weil das Backup hängt, abgestürzt ist oder der Zeitplan-Eintrag gelöscht wurde — schlägt Kuma auf das Schweigen hin Alarm. Das ist wie der Totmannschalter im Zug: Wird er nicht regelmäßig betätigt, wird gebremst. Damit erwischst du eine ganze Fehlerklasse, die kein Erreichbarkeitstest je sieht — nämlich Jobs, die schlicht nicht mehr laufen.
Alarm geben: Benachrichtigungen einrichten
Kuma kennt über 90 Benachrichtigungswege. Gängig sind Telegram, Discord, Slack, Matrix und E-Mail (SMTP), dazu die selbst gehosteten Push-Dienste ntfy und Gotify, die Meldungen ohne fremde Cloud aufs Handy bringen. Apprise ist als Sammelanbindung integriert und bündelt Dutzende weitere Kanäle über eine Konfigurationszeile; auch Home Assistant lässt sich anbinden.
Zwei Einschränkungen solltest du kennen: SMS, Signal und WhatsApp verschickt Kuma nicht selbst, sondern nur über Drittanbieter-Gateways. Und eine offizielle Handy-App gibt es nicht — Push läuft über ntfy, Pushover, Telegram und Ähnliches. Apps im Store, die „Uptime Kuma“ heißen, stammen nicht vom Projekt.
Gegen Alarm-Spam gibt es pro Monitor drei Stellschrauben: Retries (wie oft eine Prüfung hintereinander fehlschlagen muss, bevor „down“ gemeldet wird), das Prüfintervall und „Resend Notification every X times“, damit ein Dauerausfall nicht im Minutentakt nervt. Ein Wartungsfenster-Modus unterdrückt Alarme während geplanter Arbeiten. Hinweis für Version 2: Neu angelegte Monitore starten jetzt mit 0 Retries statt 1 — ohne Nachjustieren melden sie kurze Aussetzer früher als „down“.
Der häufigste Fehler: Der Wächter im selben Boot
Läuft Uptime Kuma auf demselben Server, den es überwachen soll — oder hinter derselben Internetleitung —, dann fällt der Wächter beim Strom-, Host- oder Anschlussausfall mit aus. Ausgerechnet der Fall, für den man Monitoring einrichtet, bleibt unbemerkt. Der Monitor gehört in eine andere „Fehlerdomäne“: anderer Rechner, idealerweise anderer Standort und anderer Anbieter.
Ebenso trügerisch ist ein einzelner Prüfpunkt. Ein Standort kann nicht beurteilen, ob ein Dienst weltweit erreichbar ist. Ein kurzer Schluckauf beim Internetanbieter am Kuma-Standort meldet dir nachts „alles down“, obwohl alles läuft. Die gängige Lösung: Kuma im Heimnetz betreiben und zusätzlich einen unabhängigen externen Dienst auf die von außen sichtbaren Adressen setzen.
Als externe Zweitinstanz wird oft der Online-Dienst UptimeRobot genannt. Achtung: Dessen kostenloser Tarif ist seit 1. Dezember 2024 auf rein private, nicht-kommerzielle Nutzung beschränkt (weiterhin 50 Monitore, 5-Minuten-Intervall). Ältere Anleitungen unterschätzen das.
db-tronic Raspberry Pi 5 4GB Starter Set
Ein separater, sparsamer Kleinrechner als Dauerläufer für Uptime Kuma — damit der Wächter nicht auf demselben Server hängt wie die überwachten Dienste. Rund 189,99 € (Stand 30.08.2026).
Was sich mit Version 2 geändert hat
Nach etwa einem Jahr offener Beta ist Version 2.0 seit Oktober 2025 stabil. Ältere Artikel, die 2.0 als „nicht produktionsreif“ bezeichnen, sind überholt. Die wichtigsten Punkte:
- MariaDB ist jetzt als Datenbank wählbar, neben dem bisherigen SQLite — gedacht für große Installationen mit hunderten Monitoren. Eine Umwandlung in der App ist eingebaut.
- Das offizielle Docker-Image läuft standardmäßig rootless, also ohne Administratorrechte im Container.
- Backup-Bruch: Der JSON-Export und -Import ist entfernt. Die einzige unterstützte Sicherung ist das Kopieren des Datenverzeichnisses. Wer noch „exportier dein JSON“ empfiehlt, liegt bei v2 falsch.
- Die Mindestversion von Node.js ist jetzt 20.4; das Frontend wurde von Vue 2 auf Vue 3 umgestellt, alte Browser fallen raus.
- Badge-Endpunkte (kleine Status-Grafiken zum Einbetten) akzeptieren nur noch feste Zeiträume: 24 Stunden, 30 Tage, 1 Jahr.
Version 2.5 vom 1. August 2026 brachte als Reaktion auf Angriffe über die npm-Lieferkette (npm ist der Paket-Katalog, aus dem Node.js-Projekte Fremdcode beziehen) einen 14-Tage-Cooldown auf Abhängigkeiten: Neue Paketversionen werden erst zwei Wochen nach Veröffentlichung übernommen, weil kompromittierte Releases meist innerhalb weniger Tage auffliegen und zurückgezogen werden. Dazu kamen der NTP-Monitor und frei wählbare, auch längere Prüfintervalle. Für das Admin-Konto gibt es unter Settings → Security eine Zwei-Faktor-Anmeldung per TOTP (Einmal-Codes aus einer Authenticator-App).
Kuma oder etwas anderes?
Uptime Kuma ist der De-facto-Standard im Homelab: ein Container, aufgeräumte Oberfläche, viele Monitor- und Alarmtypen, sehr aktive Community. Schwächen sind der einzelne Betriebspunkt und eher schlichte Statusseiten. Zwei Alternativen, die häufig parallel laufen:
| Werkzeug | Ansatz | Gut für |
|---|---|---|
| Uptime Kuma | Weboberfläche, Konfiguration per Klick, rund 30 Monitor-Typen | Der Allrounder für die meisten Homelabs |
| Gatus | Health-Checks als YAML-Datei, in Git versionierbar; einzelnes Go-Programm, ressourcenärmer als Kumas Node-Prozess | Wer Konfiguration als Code will |
| Healthchecks | Reiner Totmannschalter für Cronjobs und Backups | Die „Lief der nächtliche Backup-Job überhaupt?“-Lücke |
Kurz zur Hardware
Weil der Monitor eben nicht auf dem NAS (Network Attached Storage, also ein Speicher, der am Netzwerk hängt) laufen soll, braucht es einen kleinen, sparsamen Dauerläufer: einen Einplatinenrechner wie den Raspberry Pi, einen Mini-PC mit N100-Prozessor oder einen günstigen VPS (einen gemieteten virtuellen Server). Für die grob 80 MB Grundlast reicht das kleinste Gerät. Ergänzend hilft eine USV (unterbrechungsfreie Stromversorgung) am NAS, damit ein kurzer Stromausfall nicht sofort als Dienstausfall durchschlägt.
Fazit
Uptime Kuma ist in einer Stunde eingerichtet und nimmt dir das „Ich hoffe, es läuft noch“ ab. Zwei Dinge entscheiden über den Nutzen: Betreibe den Wächter getrennt von dem, was er überwacht, und ergänze ihn um einen externen Checker auf deine nach außen sichtbaren Dienste. Für Backups und Cronjobs nimmst du den Push-Monitor. Dann merkst du einen Ausfall, bevor es jemand anders tut.