Uptime Kuma: KMU-Uptime-Page mit HTTP-, TCP-, Ping- und Docker-Checks

Was ist Uptime Kuma?

Uptime Kuma ist eine selbst gehostete Uptime-Monitoring-Lösung, 2021 von Louis Lam als Antwort auf das proprietäre Uptime-Robot gestartet. Mittlerweile (Mai 2026) hat das Projekt über 60.000 GitHub-Sterne und ist das wohl beliebteste Open-Source-Uptime-Tool. Lizenz: MIT – vollständig frei, ohne Klauseln, ohne Open-Core-Limits.

Das Konzept ist bewusst klein gehalten: Uptime Kuma prüft regelmässig (Intervall wählbar, Standard 60 Sekunden), ob ein Endpunkt antwortet. Wenn nicht, geht ein Alert raus – Telegram, Slack, Discord, Gotify, ntfy, E-Mail, oder 90+ andere Receiver. Die UI zeigt eine Liste aller Monitore mit grünen/roten Lampen und einer Heatmap der letzten 24 Stunden, 30 Tage und 1 Jahr.

13+ Monitor-Typen werden unterstützt: HTTP(s) mit Status-Code-Prüfung, HTTP(s) mit Keyword-Match im Response-Body, TCP-Port, DNS-Lookup, Push (Heartbeat von einem externen Job), Ping (ICMP), Docker-Container, Steam-Server, gRPC, MQTT, MongoDB, PostgreSQL, MySQL, Redis, Kafka. Damit deckt Uptime Kuma fast alle KMU-Bedarfe ab.

Besonderheit: Status-Page. Eine öffentliche oder per-Token-geschützte Status-Page lässt sich in der UI zusammenklicken – typisch für eine SaaS-Plattform, die Kunden über Outages informieren will. URL-Slug frei wählbar, eigenes Logo, Custom-CSS. Damit hat ein KMU eine professionelle "status.firma.ch"-Seite ohne extra Komponenten.

Footprint: ein Docker-Container, SQLite oder MariaDB als Backend, ca. 150 MB RAM im Leerlauf. Läuft auf einem 1-vCPU-Server problemlos. Setup: docker run, Browser auf Port 3001, Admin-Account anlegen, fertig. Realistisch in 5 bis 10 Minuten produktiv.

Warum es zählt

Uptime Kuma löst für KMU genau den Bedarf, der mit Prometheus zu viel und mit gar nichts zu wenig ist: zu wissen, ob die externen Endpunkte (Webseiten, APIs, Datenbank-Ports, Mail-Server) erreichbar sind. Prometheus prüft das über den blackbox-exporter, aber dafür braucht es einen ganzen Grafana-Stack. Uptime Kuma liefert dieselbe Funktion in einem einzigen Container mit eigener UI.

KMU-Tauglichkeit (Mai 2026): das wohl niedrigste Setup-Investment im Monitoring-Bereich. Ein Treuhand-Büro mit einer Webseite, einer Bexio-Anbindung, einem Mail-Server und einer Backup-NAS hat in 30 Minuten vier Monitore plus eine Status-Page eingerichtet – ohne YAML, ohne PromQL, ohne Grafana. Alerts gehen an Telegram, fertig.

CH-DSG-Fit: Uptime Kuma läuft self-hosted in Docker. Die Daten – wann antwortet welcher Endpunkt? – bleiben auf dem eigenen Server. Keine US-Komponente, keine Daten-Transfer-Diskussion. Für Mandanten unter Berufsgeheimnis (StGB 321) ist das die saubere Variante gegenüber kommerziellen Cloud-Diensten wie Uptime Robot oder Better Uptime.

Status-Page als Vertrauens-Element: Eine öffentliche Status-Page (status.firma.ch) zeigt Kunden und Partnern, dass das Unternehmen Monitoring ernst nimmt. Bei einem Outage ist die Kommunikation transparenter – Kunden sehen die Störung selbst und rufen seltener an. Für SaaS-orientierte KMU ein wichtiges Tool für Kundenvertrauen.

Push-Heartbeat für Cron-Jobs: Ein wenig bekanntes Feature. Ein Cron-Job (Backup, Mahnung-Versand, Newsletter) sendet alle X Minuten ein HTTP-Heartbeat an einen Uptime-Kuma-Push-Monitor. Fällt der Cron aus, ist Uptime Kuma nach Timeout der erste, der bescheid weiss. Damit lassen sich auch "unsichtbare" Routinen überwachen, die kein eigenes /health-Endpoint haben.

Wie es funktioniert

Uptime Kuma ist eine Node.js-Anwendung mit eingebauter Web-UI (Vue.js). Ein Hauptprozess führt Probes aus, schreibt Ergebnisse in eine SQLite- oder MariaDB-Datenbank und stellt Alerts über konfigurierte Receiver zu.

docker-compose.yml-Beispiel:

```yaml services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma volumes: - uptime-kuma-data:/app/data ports: ["3001:3001"] restart: unless-stopped volumes: uptime-kuma-data: ```

Nach dem ersten Start: Browser auf http://server:3001, Admin-Account anlegen (Username + Passwort), fertig. Hinter einem nginx-Reverse-Proxy mit Lets-Encrypt-Zertifikat läuft das produktiv auf status.firma.ch.

Monitor anlegen: + Add New Monitor, Typ wählen (HTTP, TCP, Push, Docker, etc.), URL/Host/Port eintragen, Intervall (Standard 60s), Retries (Standard 0), Notification-Receiver auswählen. Fertig in 30 Sekunden.

Notification-Receiver: Telegram-Bot mit chat_id und token, Slack-Webhook, Discord-Webhook, Gotify, ntfy.sh, Webhook (eigener Endpunkt), SMTP (eigener Mail-Server), Apprise (Brückenservice für 80+ weitere Services). Mehrere Receiver pro Monitor möglich.

Status-Page anlegen: Status Pages → + Add New, Slug wählen (z.B. "public"), Monitore zuordnen, Theme wählen, Custom-Domain optional via nginx-Subdomain. Public oder Token-geschützt. Die Status-Page wird automatisch aktualisiert, Kunden brauchen kein Login.

Docker-Container-Monitor: ein spezieller Typ. Statt einen Port zu prüffen, prüft Uptime Kuma direkt am Docker-Socket, ob der Container "running" und "healthy" (falls Healthcheck definiert) ist. Damit erkennt es auch Container, die zwar laufen, aber nicht antworten – z.B. ein Process-Crash innerhalb eines Containers.

Push-Monitor für Cron: Uptime Kuma generiert eine URL wie `/api/push/abc123?status=up&msg=ok`. Der Cron-Job ruft diese URL via curl auf. Wenn kein Aufruf in X Minuten kommt, schlägt Uptime Kuma Alarm. Sehr nützlich für Backup-Jobs, Mahnung-Cron, Cleanup-Skripte.

Setup in 5 Schritten

1. 01docker-compose mit louislam/uptime-kuma:1 starten, Volume persistieren, Port 3001 freischalten.
2. 02Admin-Account anlegen, danach Auto-Lock auf Login-Versuche aktivieren (Settings → Auth Rate Limit).
3. 03Telegram-Bot anlegen, chat_id ermitteln, in Uptime Kuma als Notification-Channel hinterlegen, Test-Notification senden.
4. 04Monitore in Reihenfolge anlegen: 1) Website-HTTP, 2) API-HTTP-Keyword, 3) PostgreSQL-Port, 4) Docker-Container, 5) Push-Heartbeat für Backup-Cron.
5. 05Status-Page anlegen, Subdomain status.firma.ch via nginx-Reverse-Proxy, Lets-Encrypt-Zertifikat, Branding (Logo, Farben) anpassen.

Wann Uptime Kuma einsetzen

Uptime Kuma ist die richtige Wahl, wenn (a) das Setup unter 25 Endpunkte/Container hat, (b) ein einfacher Erreichbarkeits-Status ausreicht (kein Drill-Down in Latenz-Histogramme), (c) eine öffentliche Status-Page gewünscht ist, (d) Setup-Zeit unter einer Stunde gefragt ist.

Konkrete KMU-Fälle: Eine Treuhand-Webseite plus Bexio-Anbindung plus Backup-NAS plus Mail-Server – vier Monitore reichen. Eine Anwaltskanzlei mit eigener Mandanten-Plattform plus PostgreSQL plus Redis – fünf bis sieben Monitore. Ein SaaS-Anbieter mit öffentlicher status.firma.ch-Seite – Uptime Kuma plus nginx-Subdomain.

Gute Ergänzung zu Prometheus: Uptime Kuma für externe Erreichbarkeit (was sieht der Kunde?), Prometheus für interne Tiefe (warum ist es langsam?). Bei Fairlane laufen beide parallel – Uptime Kuma für 14 öffentliche Endpunkte mit Telegram-Alerts, Prometheus für 25 Container-interne Metriken. Setup-Aufwand für Uptime Kuma: 20 Minuten, laufender Pflegeaufwand: nahe null.

Wann NICHT

Uptime Kuma ist die falsche Wahl, wenn (a) tiefes Application-Performance-Monitoring nötig ist – Latenz-Histogramme, P95/P99, Error-Rates pro Endpoint – dann Prometheus plus Grafana, (b) Log-Analyse das Hauptthema ist – dann Loki, (c) das Setup über 50+ Endpunkte wächst und Multi-Tenant-fähig sein muss – dann Zabbix oder Datadog.

Fallen: Uptime Kuma als alleinige Monitoring-Lösung für komplexe RAG- oder LLM-Pipelines verwenden – es sieht nur, ob der HTTP-Endpoint antwortet, nicht ob das Modell halluziniert oder die Latenz steigt. Alerts auf 60-Sekunden-Intervall ohne Retries setzen – flackernde Probes erzeugen False-Positives. Status-Page öffentlich machen mit Bezeichnungen, die Geschäftsinterna verraten ("Mandanten-CRM v2.5 Prod") – Angreifer freuen sich über Architektur-Hinweise.

Nicht empfohlene Muster: Uptime Kuma plus Uptime Robot plus Pingdom parallel – drei UIs, drei Alert-Streams, dreifache Alert-Fatigue. Push-Monitor ohne Cron-Watchdog – wenn der Cron-Job selbst stirbt, kann er auch keinen Heartbeat senden. Daher zusätzlich systemd-Timer-Health-Check oder Container-Healthcheck einplanen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Uptime Kuma – GitHub repository · 2026-05
2. Uptime Kuma – Documentation Wiki · 2026-04
3. Apprise – Notification bridge service · 2026-03
4. Self-hosted comparison – Uptime tools 2026 · 2026-04