Wer Dutzende eigenständige Websites betreibt, merkt einen Ausfall oder ein abgelaufenes TLS-Zertifikat oft zuerst an einer Kundenbeschwerde, nicht an einer eigenen Meldung. Ein TLS-Zertifikat ist die kryptografische Bescheinigung, mit der ein Server seine Identität gegenüber Browsern nachweist; läuft es ab, zeigt jeder Browser eine Sicherheitswarnung, bevor die Seite überhaupt lädt. Uptime Kuma ist ein selbstgehostetes, quelloffenes Werkzeug, das beide Probleme aus einer einzigen Instanz heraus löst: Es prüft laufend, ob eine Website erreichbar ist, und liest dabei nebenbei das TLS-Zertifikat mit.
Das Projekt wird aktiv weiterentwickelt. Version 2.5.3 erschien am 22. August 2026, und das GitHub-Repository zählt mehrere tausend Commits sowie eine laufend aktive Issue- und Pull-Request-Liste. Seit Juni 2025 kommt der eigenen Zertifikatsautomatisierung dabei eine zusätzliche Aufgabe zu: Let's Encrypt, der mit Abstand meistgenutzte kostenlose Zertifikatsaussteller, hat seinen eigenen Ablaufmail-Dienst eingestellt und verweist Nutzer seither ausdrücklich auf Monitoring-Werkzeuge von Drittanbietern.
Systemvoraussetzungen
Eine Uptime-Kuma-Instanz kommt mit wenigen, klar benannten Bausteinen aus. Die folgende Tabelle listet sie mit den aktuellen Versions- und Konfigurationsangaben aus der offiziellen Installationsdokumentation des Projekts.
| Komponente | Version oder Anforderung | Zweck |
|---|---|---|
| Uptime-Kuma-Image | louislam/uptime-kuma:2, aktuell Version 2.5.3 (22. August 2026) | Monitoring-Server mit Weboberfläche, Prüf-Engine und SQLite-Datenbank |
| Docker Engine | ab Version 20.10 mit Compose-Plugin (docker compose) | Betrieb und automatischer Neustart des Containers |
| Datenverzeichnis | Host-Verzeichnis oder benanntes Volume, gemountet auf /app/data | Speichert Monitore, Ereignisverlauf und Zertifikatsdaten dauerhaft; verlangt vollständige POSIX-Dateisperren |
| Offener Port | TCP 3001 (Host-seitig frei wählbar) | Zugriff auf die Weboberfläche |
| Ausgehende Verbindungen | HTTPS, TCP und DNS zu jedem überwachten Ziel | Durchführung der Checks und des TLS-Handshakes für die Zertifikatsprüfung |
| Alternative ohne Docker | Node.js ab Version 20.4, zusätzlich Git und PM2 | Installation direkt auf einem Linux-, Windows- oder macOS-Host |
Systemarchitektur
Ein einzelner Uptime-Kuma-Container überwacht beliebig viele Websites gleichzeitig. Jede überwachte Adresse bekommt einen eigenen Monitor, eine Konfigurationseinheit mit Intervall, Prüftyp und Schwellenwerten. Uptime Kuma unterstützt dabei mehrere Monitor-Typen nebeneinander: HTTP(s) für Websites, TCP für Datenbanken oder andere Portdienste, DNS Record für die Namensauflösung, Ping, Websocket und einen eigenen Docker-Container-Monitor, der den Status eines Containers direkt über den Docker-Socket abfragt, ohne dass der Container selbst einen Netzwerkport öffnen muss.
flowchart TD
A[Ein Uptime Kuma Container ueberwacht das Portfolio] --> B[Zeitgesteuerter HTTPS Check fuer Website A]
A --> C[Zeitgesteuerter HTTPS Check fuer Website B]
A --> D[TCP oder DNS Check fuer weitere Dienste]
B --> E[TLS Handshake liest das Zertifikat mit]
E --> F[Resttage werden mit den Schwellenwerten verglichen]
F -->|Resttage ueber der Schwelle| G[Kein Alarm naechster Check nach Intervall]
F -->|Resttage unter der Schwelle| H[Zertifikatswarnung wird ausgeloest]
B -->|Verbindung schlaegt wiederholt fehl| I[Ausfall wird nach Anzahl der Retries bestaetigt]
H --> J[Gemeinsamer Benachrichtigungskanal fuer alle Monitore]
I --> J
J --> K[Zustaendiges Team prueft die Ursache]
K --> L[Oeffentliche Statusseite bei echter Stoerung aktualisieren]
Die Zertifikatsprüfung ist kein eigener Monitor-Typ, sondern ein automatischer Nebeneffekt jedes HTTP(s)-Monitors. Bei jedem Check liest Uptime Kuma das Zertifikat während des TLS-Handshakes mit und speichert Aussteller, Ablaufdatum und die verbleibende Restlaufzeit in Tagen. Pro Monitor lässt sich diese Prüfung über ein eigenes Kontrollkästchen namens Certificate Expiry Notification an- und abschalten. Wie viele Tage vor Ablauf gewarnt wird, legt eine globale Einstellung fest, die im Quellcode des Projekts als tlsExpiryNotifyDays geführt wird. Ohne eigene Anpassung greift die Standardliste 7, 14 und 21 Tage vor dem Ablaufdatum, wobei jede erreichte Schwelle eine eigene Benachrichtigung auslöst.
Ausfall und Zertifikatswarnung laufen anschließend über denselben Weg zum Team. Beim Anlegen eines Benachrichtigungskanals bietet Uptime Kuma zwei Kontrollkästchen: Default Enabled aktiviert den Kanal automatisch für jeden künftig neu angelegten Monitor, Apply on all existing monitors trägt ihn zusätzlich sofort in jeden bereits bestehenden Monitor ein. Ein einziger konfigurierter Kanal reicht damit für ein Portfolio aus vierzig oder vierhundert Websites, ohne dass jeder Monitor einzeln verknüpft werden muss.
Schritt-für-Schritt-Umsetzung
Uptime Kuma per Docker Compose bereitstellen
Die offizielle Compose-Datei des Projekts kommt mit drei Angaben aus: dem Image, einem Datenvolume und dem Port für die Weboberfläche.
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
# <Host-Port>:<Container-Port>
- "3001:3001"
docker compose up -d
Der erste Aufruf von http://server-adresse:3001 im Browser legt das erste Administratorkonto an, ein zusätzlicher Anmeldebildschirm entfällt danach. Das Verzeichnis ./data enthält die SQLite-Datenbank mit allen Monitoren und gehört deshalb ins reguläre Server-Backup. Läuft der Container auf einem Dateisystem ohne vollständige POSIX-Dateisperren, etwa bestimmten Netzwerkfreigaben, drohen laut der Installationsdokumentation Beschädigungen an dieser Datenbank.
Einen Monitor für eine Website anlegen
- Neuen Monitor anlegen. Über die Schaltfläche Add New Monitor in der Weboberfläche öffnet sich das Formular für einen neuen Prüfpunkt.
- Monitor-Typ und Adresse eintragen. Für eine Website steht dort der Typ HTTP(s), dazu die vollständige URL mit Protokoll.
- Intervalle setzen. Das Heartbeat-Intervall bestimmt den Abstand zwischen zwei Checks, Retries die Zahl der Fehlversuche, bevor ein Ausfall als bestätigt gilt.
- Zertifikatsprüfung aktivieren. Das Kontrollkästchen Certificate Expiry Notification schaltet die TLS-Ablaufwarnung für genau diesen Monitor ein.
- Benachrichtigungskanal zuweisen. Ist der gemeinsame Kanal bereits als Default Enabled markiert, ist dieser Schritt für neue Monitore bereits erledigt.
Monitor-Typ: HTTP(s)
Freundlicher Name: Website A
URL: https://website-a.beispiel.de
Heartbeat-Intervall: 60 Sekunden
Retries: 3
Heartbeat-Wiederholungsintervall: 30 Sekunden
Certificate Expiry Notification: aktiviert
Benachrichtigungen: Portfolio-Sammelkanal
Nach dem Speichern zeigt die Monitor-Seite den aktuellen Status und ein Zertifikatsfeld mit Aussteller und Resttagen. Wer die Werte zusätzlich in ein bestehendes Monitoring einspeisen will, findet dieselben Angaben auf dem Prometheus-kompatiblen Endpunkt der Instanz wieder.
curl -s http://server-adresse:3001/metrics | grep monitor_cert_days_remaining
Einen gemeinsamen Benachrichtigungskanal einrichten
Ein einziger Kanal reicht für das ganze Portfolio, wenn er beim Anlegen korrekt markiert wird. Uptime Kuma unterstützt dafür eine große Zahl nativer Anbieter, darunter Slack, Discord, Telegram, Signal, Matrix, Microsoft Teams, ntfy, PagerDuty, Opsgenie, Gotify, Pushover, generische Webhooks und E-Mail über SMTP, zusätzlich vermittelt über die Anbindung an Apprise weitere Dutzende Dienste.
Benachrichtigungstyp: Slack
Webhook-URL: https://hooks.slack.com/services/...
Default Enabled: ja
Apply on all existing monitors: ja
Default Enabled sorgt dafür, dass jeder ab jetzt neu angelegte Monitor den Kanal automatisch erhält. Apply on all existing monitors trägt ihn zusätzlich in jeden Monitor ein, der zum Zeitpunkt des Speicherns bereits existiert; intern verknüpft Uptime Kuma dafür die Kennung des Kanals mit jedem vorhandenen Monitor in einer eigenen Zuordnungstabelle. Beide Kontrollkästchen zusammen verhindern, dass ein neues oder ein altes Portfoliomitglied beim Anlegen des Kanals vergessen wird.
Häufige Fehlerquellen
- Ignorierte TLS-Fehler blenden auch die Ablaufwarnung aus. Ist bei einem Monitor die Option Ignore TLS/SSL error aktiviert, etwa um ein selbstsigniertes Zertifikat in einer Testumgebung zuzulassen, bleibt laut einem im Bugtracker des Projekts dokumentierten Fall auch für das echte Produktivzertifikat die erwartete Ablaufwarnung aus. Fix: Die Option nur für echte Testumgebungen setzen, nie für ein Live-Zertifikat.
- Ein neuer Kanal erreicht nur neue Monitore. Wird beim Anlegen eines Benachrichtigungskanals nur Default Enabled gesetzt, gilt er ausschließlich für Monitore, die danach entstehen. Fix: Zusätzlich Apply on all existing monitors aktivieren oder den Kanal nachträglich manuell an jedem bestehenden Monitor ergänzen.
- Falscher Alarm durch den eigenen Netzwerkpfad. Prüft Uptime Kuma mehrere Ziele im Minutentakt, kann eine Ratenbegrenzung oder Firewall auf der Gegenseite genau diese Prüf-IP blockieren, während echte Besucher die Website weiterhin normal erreichen. Ein dokumentierter Fall aus dem Bugtracker des Projekts zeigte ein Muster aus stundenlangem Down-Status und kurzen Erholungsphasen, das zu einer serverseitigen Ratenbegrenzung passte. Fix: Die IP-Adresse der Uptime-Kuma-Instanz beim überwachten Dienst auf eine Positivliste setzen und Retries erhöhen, bevor ein Ausfall gemeldet wird.
- Die SQLite-Datenbank beschädigt sich auf ungeeignetem Speicher. Läuft das Datenverzeichnis auf einer Netzwerkfreigabe ohne vollständige POSIX-Dateisperren, kann die interne Datenbank beschädigt werden. Fix: Ausschließlich lokalen Speicher oder ein natives Docker-Volume für
/app/dataverwenden. - Interne Ziele bleiben wegen des Docker-Netzwerks unerreichbar. Läuft Uptime Kuma in einem Docker-Netzwerktyp ohne Zugriff auf das lokale Netzwerk, meldet ein Monitor für einen internen Dienst dauerhaft Ausfall, obwohl der Dienst tatsächlich läuft. Fix: Den Container in dasselbe Docker-Netzwerk wie den Zieldienst hängen oder testweise direkt im Container mit
curlundpingprüfen, ob die Verbindung grundsätzlich zustande kommt. - IPv6-Adressen werden fälschlich als Ausfall gewertet. Docker aktiviert IPv6 nicht standardmäßig. Ein Ziel mit funktionierender IPv4-Adresse, aber nicht erreichbarer IPv6-Adresse kann deshalb als Ausfall erscheinen, obwohl die Website für die meisten Besucher normal lädt. Fix: IPv6 im Docker-Daemon gezielt aktivieren oder den Monitor testweise auf die IPv4-Adresse festlegen.
Häufig gestellte Fragen
Prüft Uptime Kuma das TLS-Zertifikat automatisch oder braucht es einen eigenen Monitor-Typ?
Uptime Kuma prüft das TLS-Zertifikat automatisch bei jedem HTTP(s)-Monitor mit, ohne dass dafür ein eigener Monitor-Typ nötig ist. Bei jedem Check liest die Software Aussteller, Ablaufdatum und Restlaufzeit direkt aus dem TLS-Handshake und vergleicht die verbleibenden Tage mit den hinterlegten Schwellenwerten. Ein separates Kontrollkästchen namens Certificate Expiry Notification schaltet diese Mitprüfung je Monitor an oder ab.
Wie viele Tage vor Ablauf warnt Uptime Kuma vor einem auslaufenden Zertifikat?
Uptime Kuma warnt in der Standardeinstellung 7, 14 und 21 Tage vor dem Ablauf eines Zertifikats, sofern niemand die Einstellung geändert hat. Jede dieser drei Schwellen löst bei Erreichen eine eigene Benachrichtigung aus, sodass ein Team nicht erst am letzten Tag erfährt, dass eine Erneuerung ausgeblieben ist. Die Liste der Tage lässt sich in den allgemeinen Einstellungen frei anpassen, etwa um bei kurzlebigen Zertifikaten engere Abstände zu setzen.
Ersetzt eine eigene Uptime-Kuma-Instanz die automatische Zertifikatsverlängerung durch Let's Encrypt?
Eine eigene Uptime-Kuma-Instanz ersetzt die automatische Verlängerung durch Let's Encrypt nicht, sondern ergänzt sie um eine unabhängige Kontrolle von außen. Die automatische Verlängerung selbst kann trotzdem scheitern, etwa wenn ein Hook-Skript nach der Erneuerung wegen eines fehlenden Programmpfads in der Cron-Umgebung stillschweigend fehlschlägt, während ein manueller Testlauf mit vollständigem Pfad noch funktioniert hätte. Seit Let's Encrypt im Juni 2025 seinen eigenen Ablaufmail-Dienst eingestellt hat, bleibt eine solche unabhängige Prüfung der einzige verlässliche Rückfallpunkt vor einer echten Ablaufwarnung im Browser der Besucher.
Woran erkennt ein Team, ob ein Alarm eine echte Störung oder einen blockierten Prüfpfad meldet?
Ein Alarm von Uptime Kuma meldet zunächst nur, dass der Check aus Sicht der Monitoring-Instanz fehlgeschlagen ist, nicht zwingend, dass die Website für echte Besucher nicht erreichbar ist. Ein typisches Muster für einen blockierten Prüfpfad ist ein wiederkehrender Wechsel zwischen Ausfall und kurzer Erholung im Minutentakt, wie er entsteht, wenn eine Ratenbegrenzung oder Firewall die Anfragen der Monitoring-Instanz blockiert. Zur Unterscheidung hilft ein manueller Aufruf der Website aus einem anderen Netz sowie die öffentliche Statusseite von Uptime Kuma, über die ein Team bestätigte Störungen unabhängig von der internen Diagnose kommunizieren kann.