Uptime Kuma: Selbst gehostetes Monitoring mit Statusseiten, Push-Prüfung und 90+ Benachrichtigungsdiensten
Uptime Kuma prüft Websites und Dienste auf dem eigenen Server, verschickt Störungsmeldungen und veröffentlicht Statusseiten.
Auf einen Blick
- Was ist das?
- Analyse des JavaScript-Projekts louislam/uptime-kuma: Prüftypen, Installationswege über Docker und PM2, Aktualisierung über das Wiki und die Grenzen dessen, was das README verspricht.
- Für wen ist es gedacht?
- Uptime Kuma passt für Betreiber kleinerer bis mittlerer Serverlandschaften, die Verfügbarkeitsprüfungen und öffentliche Statusseiten selbst kontrollieren wollen, mit Prüftypen von HTTP(s) bis Docker-Containern. Weniger geeignet ist es, wenn NFS-Speicher eingeplant ist oder pauschale Leistungszahlen für großen Enterprise-Betrieb erwartet werden.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Selbst gehostete Verfügbarkeitsprüfung als Antwort auf Uptime Robot und statping
Uptime Kuma ist ein leicht bedienbares, selbst gehostetes Monitoring-Werkzeug, das laut Repository-Metadaten auf JavaScript aufbaut und unter der MIT-Lizenz steht. Die Zahlen sind beachtlich: über 90.000 Sterne und rund 8.300 Forks, der master-Zweig wurde Ende August 2026 zuletzt gepusht. Aktuelle Releases folgen dicht aufeinander, 2.5.1, 2.5.2 und 2.5.3 erschienen alle am 22. August 2026, was auf intensive Wartung hindeutet.
Die Motivationssektion des README erklärt die Herkunft des Projekts. Der Autor Louis Lam suchte ein selbst gehostetes Gegenstück zu Uptime Robot, fand aber kaum passende Kandidaten; statping, eines der näheren, war instabil und wurde nicht mehr gepflegt. Daneben nannte er als Ziele, eine aufwendige Oberfläche zu bauen, Vue 3 und vite.js zu lernen, Bootstrap 5 zu demonstrieren, WebSocket mit einer Single-Page-Anwendung statt einer REST-API einzusetzen und sein erstes Docker-Image auf Docker Hub zu veröffentlichen. Das erklärt, warum das Projekt so stark auf Frontend-Erlebnis setzt. Eine temporäre Live-Demo läuft auf einem Server in Frankfurt, alle Daten dort werden nach zehn Minuten gelöscht.
Prüftypen von TCP und DNS-Records bis Steam-Server und Docker-Containern
Die Funktionsliste nennt elf Prüftypen: HTTP(s), TCP, HTTP(s)-Keyword, HTTP(s)-Json Query, WebSocket, Ping, DNS-Eintrag, Push, Steam Game Server und Docker-Container. Damit deckt das Tool sowohl klassische Webauftritte als auch Dienste ab, die bei generischen Monitorern meist fehlen, etwa Spielserver oder Container-Laufzeitstatus. Das Prüfintervall liegt bei bis zu 20 Sekunden, das README sagt jedoch nicht, ob und wie sich dieses Intervall konfigurieren lässt.
Ergänzend kommen Merkmale hinzu, die den Betriebsalltag betreffen: mehrere Statusseiten mit Zuordnung zu bestimmten Domains, ein Ping-Chart, Zertifikatsinformationen, Proxy-Unterstützung und Zwei-Faktor-Authentifizierung für den Zugriff. Die Oberfläche ist mehrsprachig, Übersetzungen werden über Weblate gepflegt. Wie die einzelnen Prüftypen im Detail konfiguriert werden, dokumentiert das README nicht; dafür verweist das Projekt auf das Installations- und Update-Wiki im Repository.
Benachrichtigungen über Telegram, Discord, Gotify, Slack und über 90 weitere Dienste
Alarme sind der Punkt, an dem Monitoring-Tools stehen oder fallen. Uptime Kuma nennt im README Telegram, Discord, Gotify, Slack, Pushover und E-Mail per SMTP als Beispiele und verlinkt für die vollständige Übersicht auf das Komponentenverzeichnis src/components/notifications, das über 90 Benachrichtigungsdienste umfasst. Das bedeutet für Selbsthoster, dass gängige Push-Dienste ohne Zusatzsoftware angebunden sind, solange der eigene Dienst in der Liste steht.
Nicht aus dem README ablesbar sind Zustellgarantien, Wiederholungslogik oder Verhaltensregeln bei Netzwerkausfällen. Wer alarmkritische Infrastruktur überwacht, sollte diese Punkte daher vor dem Produktiveinsatz anhand der Quelltexte im genannten Verzeichnis und eigener Tests klären, etwa mit einem Testmonitor, der absichtlich ausgelöst wird. Für deutsche Nutzer ist auch relevant, dass die Demo-Infrastruktur in Frankfurt betrieben wird, was die Latenz beim Ausprobieren niedrig hält, wobei die Demo nach zehn Minuten alle Daten verwirft.
Docker-Start auf Port 3001 und die NFS-Warnung des README
Der Compose-Weg besteht aus drei Befehlen: mkdir uptime-kuma, curl der compose.yaml aus dem master-Zweig und docker compose up -d. Alternativ genügt der Einzeiler docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2. Danach lauscht die Anwendung auf allen Netzwerkschnittstellen, erreichbar unter http://localhost:3001 oder http://eigene-ip:3001.
Zwei Hinweise sind betriebskritisch. Erstens warnt das README ausdrücklich, dass Netzwerkdateisysteme wie NFS nicht unterstützt werden; das Datenvolume muss auf ein lokales Verzeichnis oder lokales Volume gemappt werden, sonst drohen Datenprobleme. Zweitens empfiehlt sich für den Betrieb hinter einem Reverse Proxy die Beschränkung der Portfreigabe auf den Loopback mit -p 127.0.0.1:3001:3001, womit das Tool nur noch lokal erreichbar ist und der Proxy den öffentlichen Zugriff übernimmt. Für Szenarien mit mehr Optionen verlinkt das README den Wiki-Eintrag zur Installation.
Der PM2-Weg mit Node.js 20.4 für Umgebungen ohne Docker
Ohne Docker verlangt das README Node.js ab Version 20.4, Git und pm2 für den Hintergrundbetrieb. Unterstützt werden gängige Linux-Distributionen wie Debian, Ubuntu, Fedora und ArchLinux sowie Windows 10 x64 und Windows Server 2012 R2 x64 oder neuer; FreeBSD, OpenBSD, NetBSD, Replit und Heroku sind ausdrücklich ausgeschlossen. Der Ablauf: git clone des Repositorys, npm run setup, dann entweder node server/server.js zum Ausprobieren oder pm2 start server/server.js --name uptime-kuma für den Dauerbetrieb.
Für den Betrieb unter PM2 dokumentiert das README zwei nützliche Zusatzbefehle: pm2 monit zeigt die laufende Konsolenausgabe, pm2 startup zusammen mit pm2 save richtet den Autostart beim Booten ein; zusätzlich wird pm2-logrotate für das Log-Management empfohlen. Wer Updates einspielt, findet die Anleitung nicht im README selbst, sondern im verlinkten Wiki-Eintrag. Die Trennung zwischen README und Wiki ist im ganzen Projekt sichtbar: Das README deckt Schnellstart und Feature-Übersicht ab, alles Vertiefende liegt im Wiki.
Community-Regeln: Support nur über Issues und Subreddit, MIT-Lizenz
Das README setzt der Support-Erwartung klare Grenzen. Der Autor bittet ausdrücklich, keine allgemeinen oder technischen Fragen per E-Mail zu senden, und empfiehlt stattdessen GitHub Issues, das Subreddit r/UptimeKuma oder eine Websuche; auf Reddit ist er als u/louislamlam erreichbar und kann dort erwähnt werden. Beiträge sind auf mehreren Wegen möglich: Pull Requests nach den Richtlinien in CONTRIBUTING.md, das Testen fremder Pull Requests, das Testen von Beta-Versionen aus den Releases, Bug-Reports über Issues und Übersetzungen über Weblate; selbst Korrekturen an Rechtschreibung und Grammatik sind willkommen.
Die MIT-Lizenz erlaubt Nutzung, Kopie, Modifikation, Verteilung und Verkauf bei Beibehaltung des Urheberrechtshinweises, ohne jede Gewährleistung. Insgesamt entsteht das Bild eines sehr aktiven, aber bewusst klein gehaltenen Community-Vertrags: Fragen laufen über öffentliche Kanäle, der Autor nimmt keine E-Mail-Supportanfragen an. Wer das Tool produktiv überwachen lassen will, profitiert von der schnellen Release-Folge im August 2026, sollte aber Leistungsfragen, Backup des Datenvolumes und Härtung des Zugangs per 2FA und Reverse Proxy selbst verproben, da das README dazu keine Aussagen macht.
Redaktionelles Fazit
Uptime Kuma passt für Betreiber kleinerer bis mittlerer Serverlandschaften, die Verfügbarkeitsprüfungen und öffentliche Statusseiten selbst kontrollieren wollen, mit Prüftypen von HTTP(s) bis Docker-Containern. Weniger geeignet ist es, wenn NFS-Speicher eingeplant ist oder pauschale Leistungszahlen für großen Enterprise-Betrieb erwartet werden. Vor dem Start sollte entschieden werden, ob Port 3001 offen bleibt oder auf 127.0.0.1 beschränkt wird, und ob Docker oder der PM2-Weg mit Node.js 20.4+ zur eigenen Umgebung passt.
Community-Notizen