SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor

Uptime Kuma selbst hosten: Websites und Server überwachen

Installieren Sie Uptime Kuma per Docker auf einem separaten VPS, überwachen Sie Websites, Ports, DNS und Cronjobs und testen Sie E-Mail- oder Telegram-Warnungen.

Was Sie erstellen

Ein einzelner kleiner Container überwacht Ihre anderen Server und Websites von außen. Er informiert Sie per E-Mail, Telegram, Discord oder Webhook, sobald einer davon nicht mehr antwortet. Uptime Kuma ist in diesem Setup ein einzelner Node-Prozess, der von einer SQLite-Datei unterstützt wird. v2 kann auch mit einer eingebetteten oder externen MariaDB ausgeführt werden. Der Container läuft daher problemlos mit 256-512 MB RAM. Er stellt außerdem ein Live-Dashboard, Verlaufsdiagramme und eine öffentliche Statusseite bereit. Die Installation besteht aus einer Compose-Datei mit zehn Zeilen. Entscheidend ist jedoch, wo Sie den Container ausführen und ob Ihre Alarme in einem Test bereits ausgelöst wurden. Ein Monitor, bei dem Sie nie nachgewiesen haben, dass er Sie erreichen kann, ist schlechter als gar keiner. Er vermittelt Ihnen ein Gefühl der Absicherung, während er tatsächlich nichts überwacht.

Überwachen Sie den Dienst von einem Ort aus, den der Ausfall nicht erreichen kann

Diese Entscheidung ist für das gesamte Konzept entscheidend und steht deshalb am Anfang. Betreiben Sie Uptime Kuma nicht auf demselben Server wie die Dienste, die es überwacht. Läuft der Monitor auf dem überwachten Server, beendet genau das Ereignis, das Sie erkennen möchten – der Ausfall des Servers oder ein erschöpfter Arbeitsspeicher – auch den Monitor. Sie erhalten dann überhaupt keinen Alarm: Das Schweigen eines ausgefallenen Monitors sieht genauso aus wie „alles ist in Ordnung“. Es gibt auch eine subtilere Fehlerquelle, solange der Server noch läuft: Ein Monitor, der auf localhost zeigt, teilt sich die CPU mit der Arbeitslast. Ein Lastanstieg lässt dann die eigene Prüfung wegen eines Timeouts fehlschlagen und setzt das Ziel fälschlich auf down, obwohl reale Benutzer weiterhin bedient werden.

Betreiben Sie Uptime Kuma daher auf einem anderen VPS als dem überwachten Server, idealerweise bei einem anderen Anbieter oder in einer anderen Region. Der Monitor sollte Ihre Dienste so erreichen, wie es Ihre Benutzer tun: über das öffentliche Internet und anhand des Hostnamens. Eine günstige Instanz reicht aus. Ein kleiner Monitoring-VPS kann alle Ihre Server überwachen. Diese Trennung ist besonders für ressourcenintensive Anwendungen wichtig. Beispielsweise kann eine PhotoPrism- oder Immich-Fotobibliothek die CPU stundenlang auslasten, während sie einen neuen Import indiziert. Ein Monitor auf derselben Hardware würde dann einen Dienst als ausgefallen melden, der lediglich stark ausgelastet ist. Um auch einen Ausfall von Kuma selbst zu erkennen, richten Sie zusätzlich von einem anderen System aus einen Push-Heartbeat per cron ein.

Voraussetzungen und Dimensionierung

  • Ein frischer Ubuntu-24.04-VPS mit Docker Engine und dem Compose-v2-Plugin, installiert aus dem eigenen apt-Repository von Docker, nicht aus dem docker.io-Distributionspaket, das oft veraltet ist.
  • 256 MB RAM reichen für einige Monitore aus. 512 MB bis 1 GB bieten ausreichend Reserven für Dutzende Monitore einschließlich des Reverse Proxy. Zwischen den Prüfungen ist die CPU-Auslastung nahezu null.
  • Eine Domain und ein DNS-A-Record, beispielsweise status.example.com, der auf den VPS zeigt, nur wenn Sie TLS und eine öffentlich erreichbare Statusseite benötigen. Eine private Instanz kann auf DNS verzichten und stattdessen ein VPN oder einen SSH-Tunnel verwenden.
  • Ausgehender Netzwerkzugriff zu den Zielen der Benachrichtigungen: SMTP zu Ihrem Mail-Provider oder HTTPS zu Telegram und Discord.

Die Compose-Datei

Fügen Sie dies in /srv/uptime-kuma/compose.yaml ein.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

Starten Sie den Container und überwachen Sie den ersten Start:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

Bei einem korrekten Start wird Listening on 3001 protokolliert, danach bleibt das Log ruhig. Drei Dinge in dieser Datei sind beabsichtigt.

127.0.0.1:3001:3001 statt 3001:3001. Docker veröffentlicht Ports über DNAT-Regeln, die ausgewertet werden, bevor ufw das Paket überhaupt sieht. Ein einfaches 3001:3001 stellt Ihr Dashboard daher unabhängig von Ihren ufw-Regeln im öffentlichen Internet bereit. Filtern lässt es sich nur über Regeln, die Sie in der eigenen DOCKER-USER-Kette von Docker hinzufügen. Die Bindung an die Loopback-Adresse hält den Dienst privat. Nur der Reverse Proxy ist öffentlich erreichbar. Dadurch kann nur der Host selbst 3001 erreichen. Für eine private Instanz ohne Proxy verwenden Sie den unten gezeigten SSH-Tunnel. Für den Zugriff über ein selbst gehostetes WireGuard-VPN müssen Sie den Port stattdessen an der WireGuard-Adresse des Servers veröffentlichen, beispielsweise über 10.8.0.1:3001:3001, und nicht über 127.0.0.1.

Ein benanntes Volume unter /app/data. Dort liegen alle Daten, die Uptime Kuma speichert: die SQLite-Datenbank, Ihre Monitore, die Benachrichtigungseinstellungen und die Logos der Statusseite. Wenn Sie das Volume verlieren, sehen Sie wieder eine leere Administrationsoberfläche. Es ist das Einzige, das Sie sichern müssen.

Das Image ist auf den Major-Tag :2 festgelegt. Das ist der aktuelle stabile Entwicklungszweig. Prüfen Sie vor dem Kopieren auf Docker Hub, welcher Major-Tag der neueste ist. Verwenden Sie niemals einen veränderlichen Tag wie latest, den das Projekt abkündigt. Ein Sprung auf eine neue Major-Version führt bei diesem Image eine Datenbankmigration aus. Diese Migration sollten Sie bewusst mit einem aktuellen Backup auslösen und nicht bei einem routinemäßigen Pull unbeabsichtigt starten.

Ein wichtiger Hinweis: /app/data muss auf einem Dateisystem mit POSIX-Dateisperren liegen. Ein lokales Docker-Volume ist dafür geeignet. Auf NFS wird die SQLite-Datenbank beschädigt und Sie erhalten SQLITE_BUSY sowie database disk image is malformed. Verwenden Sie daher niemals eine Netzwerkfreigabe.

Erster Start: Administratorkonto erstellen

Rufen Sie die Instanz über Ihren Proxy unter https://status.example.com oder über einen SSH-Tunnel auf: Führen Sie ssh -L 3001:127.0.0.1:3001 user@your-vps aus und öffnen Sie http://localhost:3001. Bei einer neuen v2-Installation werden Sie im ersten Bildschirm gefragt, welche Datenbank verwendet werden soll. Wählen Sie SQLite. Die Datenbank speichert alle Daten im Volume /app/data. Die folgenden Schritte zur Sicherung und Fehlerbehebung setzen dies voraus. Anschließend wird ein Einrichtungsformular für den Administratorbenutzernamen und das Passwort angezeigt. Es gibt keine Standardanmeldung. Verwenden Sie ein sicheres Passwort. Dieses Dashboard kennt die internen Adressen und Tokens aller überwachten Systeme. Haben Sie das Passwort später vergessen? Setzen Sie es auf dem Host zurück, nicht im Browser:

sudo docker compose exec uptime-kuma npm run reset-password

Fügen Sie zuerst Ihre Benachrichtigungskanäle hinzu und testen Sie sie

Richten Sie die Benachrichtigungen vor dem Hinzufügen von Monitoren ein. Dadurch können Sie beim Erstellen jedes Monitors einen Kanal zuweisen. Öffnen Sie Settings then Notifications then Setup Notification und verwenden Sie bei jedem Kanal die Schaltfläche Test, um den Empfang der Nachricht zu bestätigen. Eine nicht getestete Benachrichtigung ist die zweithäufigste Ursache dafür, dass eine Einrichtung unbemerkt fehlschlägt.

Email (SMTP). Tragen Sie Host, Port, Verschlüsselung, Benutzernamen, Passwort sowie From und To ein. Übliche Kombinationen sind 465 mit der Einstellung "Secure" auf TLS/SSL oder 587 mit STARTTLS. Einige Server bieten STARTTLS auch auf 25 an. Verwenden Sie daher den Port und den Modus, die Ihr Provider dokumentiert. Für Gmail und die meisten Provider mit Zwei-Faktor-Authentifizierung müssen Sie ein app password erstellen. Ein normales Kontopasswort führt zu Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. Senden Sie @BotFather und geben Sie /newbot ein, um das Bot-Token zu kopieren. Für Ihre Chat-ID senden Sie dem neuen Bot zunächst eine Nachricht, öffnen https://api.telegram.org/bot<token>/getUpdates und lesen chat.id aus dem JSON ab. Ein Bot, dem Sie noch keine Nachricht gesendet haben, hat ein leeres getUpdates und kann keine Nachricht zustellen.

Discord. Öffnen Sie im Kanal Edit Channel then Integrations then Webhooks then New Webhook, kopieren Sie die URL und fügen Sie sie als Discord-Benachrichtigung ein.

Generic webhook. Für alle anderen Fälle, etwa einen eingehenden Slack-Webhook, einen benutzerdefinierten Endpunkt oder einen Hook für die Heimautomatisierung, sendet der Typ Webhook eine JSON-Nutzlast per POST an eine von Ihnen angegebene URL. Die integrierte Apprise-Integration unterstützt die meisten der knapp neunzig weiteren Dienste in der Liste. Wenn zwischen einem Ausfall und Ihrem Telefon kein Drittanbieter stehen soll, wählen Sie den integrierten Typ ntfy und verweisen Sie auf einen ntfy-Server, den Sie selbst betreiben. Dieser sendet die Benachrichtigungen über einen von Ihnen vollständig kontrollierten Kanal an Ihr Mobilgerät.

Monitore hinzufügen, einen Typ nach dem anderen

Klicken Sie auf Add New Monitor, wählen Sie einen Typ aus und legen Sie den Friendly Name, das Check Interval (60 seconds ist ein sinnvoller Wert), die Retries (aufeinanderfolgende Fehler, bevor der Status „down“ lautet; 2 oder 3 verhindern eine Benachrichtigung wegen eines einzelnen verlorenen Pakets) sowie die auszulösenden Benachrichtigungen fest. Sie werden folgende Typen verwenden:

  • HTTP(s). Eine vollständige URL. Der Status ist „up“, wenn ein akzeptierter Statuscode zurückgegeben wird (standardmäßig 200-299; erweitern Sie den Bereich unter Accepted Status Codes, wenn 301 oder 401 bei Ihnen normal ist). Dieser Typ eignet sich hauptsächlich für Websites und APIs.
  • HTTP(s) - Keyword. Dieselbe Anfrage, aber der Status ist nur dann „up“, wenn eine Zeichenfolge im Antworttext vorhanden ist oder bei Invert nicht vorhanden ist. Damit erkennen Sie, wenn die Website 200 OK zurückgibt, gleichzeitig aber „Error establishing a database connection“ anzeigt. Eine einfache HTTP-Prüfung würde diesen Zustand als fehlerfrei bewerten. Dieser Typ eignet sich auch für ein Browser-Frontend, das mit einem separaten Backend kommuniziert, beispielsweise ein Halcyon-Videostore-Theme für Jellyfin, dessen Seitengerüst problemlos 200 zurückgibt, obwohl der dahinterliegende Medienserver nicht erreichbar ist.
  • TCP Port. Eine einfache TCP-Verbindung zu einem Host und Port für Dienste, die kein HTTP verwenden: SSH auf 22, Postgres auf 5432, ein SMTP-Server auf 25 oder ein Gameserver.
  • Ping. Ein ICMP-Echo für eine kostengünstige Prüfung von Erreichbarkeit und Latenz. Viele Netzwerke und Cloud-Firewalls verwerfen ICMP jedoch. Ein roter Ping-Monitor kann daher bedeuten, dass der Host nicht erreichbar ist oder dass der Provider Ping blockiert. Überprüfen Sie dies mit einem TCP-Monitor.
  • DNS. Löst einen Record (A, AAAA, MX, TXT und weitere) über einen von Ihnen angegebenen Resolver auf und kann die Antwort prüfen. Dadurch lassen sich Ausfälle beim Registrar oder beim DNS frühzeitig erkennen.
  • Push. Der Monitor, der von innen nach außen arbeitet. Dieser Typ wird im nächsten Abschnitt behandelt.

Überwachung eines Cron-Jobs mit einem Push-(Heartbeat-)Monitor

Jeder oben beschriebene Monitor greift von außen auf Ihren Dienst zu. Ein Push-Monitor arbeitet umgekehrt: Uptime Kuma wartet, und Ihr Job ruft ihn auf, um zu melden: „Ich wurde ausgeführt.“ Das ist die einzige verlässliche Methode, ein Backup oder einen Cron-Job zu überwachen. Eine HTTP-Prüfung stellt nur fest, dass eine URL antwortet. Nur der Job selbst weiß, ob er abgeschlossen wurde.

Erstellen Sie einen Monitor vom Typ Push. Uptime Kuma generiert eine eindeutige URL wie:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Setzen Sie das Heartbeat-Intervall auf das Ausführungsintervall des Jobs und geben Sie etwas zusätzliche Toleranz hinzu. Fügen Sie anschließend eine Zeile an das Ende des Skripts ein, damit sie nur bei Erfolg ausgeführt wird:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

Wenn der Job fehlschlägt, bricht set -e vor dem curl-Aufruf ab. Wenn der Server nicht verfügbar ist, wird der Aufruf ebenfalls nicht ausgeführt. In beiden Fällen bleibt der Heartbeat aus. Sobald das Intervall zuzüglich der Wiederholungsversuche abgelaufen ist, setzt Uptime Kuma den Monitor auf down und benachrichtigt Sie. Behandeln Sie dieses Push-Token als geheim. Jeder, der es besitzt, kann einen erfolgreichen Heartbeat vortäuschen.

Eine öffentliche Statusseite erstellen

Eine Statusseite ist die kundenorientierte Ansicht. Sie zeigt, welche Dienste verfügbar sind und wie ihr aktueller Verlauf aussieht, ohne das Dashboard offenzulegen. Öffnen Sie Status Pages then New Status Page, vergeben Sie einen Namen und einen Slug (den öffentlichen Pfad, z. B. /status/main), und ziehen Sie die gewünschten Monitore in Gruppen wie „Websites“ und „APIs“. Fügen Sie ein Logo und eine kurze Beschreibung hinzu und klicken Sie auf Save. Sie können die Seite auch an eine eigene Domain binden, sodass status.example.com sie direkt ausliefert.

Beachten Sie zwei Punkte: Fügen Sie nur Monitore hinzu, die Sie öffentlich sichtbar machen möchten. Eine Statusseite zeigt, dass ein Dienst vorhanden ist und ob er verfügbar ist. Das Dashboard bleibt durch Ihren Login geschützt. Die Statusseite ist dagegen absichtlich öffentlich und erfordert keine Authentifizierung.

Setzen Sie es hinter einen Reverse Proxy mit TLS und berücksichtigen Sie WebSockets

Bei einer öffentlich erreichbaren Instanz setzen Sie für TLS und einen Hostnamen einen Reverse Proxy vor den an die Loopback-Adresse gebundenen Container. Der entscheidende Punkt, an dem die Konfiguration häufig scheitert: Die Benutzeroberfläche von Uptime Kuma ist eine Live-Anwendung auf Basis von Socket.IO. Der Proxy muss daher die WebSocket-Verbindung aufrüsten. Fehlt diese Einstellung, wird die Seite zwar geladen, aber die Verbindung kommt nicht zustande. Das Dashboard bleibt bei „Connecting...“ stehen, Live-Heartbeats werden nicht aktualisiert und die Browserkonsole zeigt WebSocket connection to 'wss://.../socket.io/...' failed.

Installieren Sie nginx und certbot. Schreiben Sie anschließend den vhost, der an den Loopback-Port weiterleitet. Verwenden Sie zunächst Port 80 und lassen Sie certbot danach TLS ergänzen. Die Challenge, der Timer für die Erneuerung und die Fehlerfälle werden in Let's-Encrypt-Zertifikate mit certbot und nginx ausstellen behandelt.

sudo apt install -y nginx certbot python3-certbot-nginx

Speichern Sie dies als /etc/nginx/sites-available/status.example.com. Die beiden WebSocket-Zeilen sind entscheidend:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

Aktivieren Sie die Site und testen Sie die Konfiguration. Lassen Sie anschließend certbot den Block so umschreiben, dass er auf 443 lauscht, das Zertifikat einbindet und eine Weiterleitung von HTTP auf HTTPS ergänzt:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Das Paar aus Upgrade und Connection "upgrade" ist entscheidend. proxy_read_timeout 3600s verhindert, dass nginx die langlebige Socket-Verbindung beendet. certbot übernimmt beide Einstellungen in den erzeugten 443-Block. Wenn Sie bereits mehrere Container hinter einem Proxy betreiben, erreichen Sie mit Routing über Traefik mit automatischem TLS dasselbe über Container-Labels. WebSocket-Upgrades werden dabei standardmäßig weitergeleitet.

Schützen Sie nicht den gesamten vhost mit Basic Authentication. Dadurch würden Sie auch die öffentliche Statusseite und den /api/push-Endpunkt sperren. Verwenden Sie weiterhin die integrierte Anmeldung von Uptime Kuma. Ergänzen Sie fail2ban zur Überwachung wiederholter fehlgeschlagener Anmeldungen, wenn die Instanz aus dem Internet erreichbar ist. Wenn das Dashboard nicht öffentlich erreichbar sein muss, entfernen Sie den Proxy und greifen Sie über einen SSH-Tunnel darauf zu. Alternativ verwenden Sie ein VPN und veröffentlichen den Port auf der VPN-Adresse statt auf der Loopback-Adresse.

Zertifikatsablaufüberwachung, richtig umgesetzt

Ein HTTP(s)-Monitor kann Sie auch vor dem Ablauf eines TLS-Zertifikats warnen: Aktivieren Sie Certificate Expiry Notification, und Uptime Kuma benachrichtigt Sie eine festgelegte Anzahl von Tagen vor dem Ablauf. Zwei Fehler führen dabei zu falschen Ergebnissen. Überwachen Sie den Dienst anhand des Hostnamens, nicht der IP-Adresse. Andernfalls erhält eine Anfrage ohne SNI das Standardzertifikat des Servers, und Sie sehen Hostname/IP does not match certificate's altnames. Aktivieren Sie außerdem Ignore TLS/SSL Error nicht für einen Monitor, von dem Sie Ablaufwarnungen erhalten möchten. Diese Option ist für selbstsignierte interne Hosts gedacht (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT). Sie verhindert jedoch, dass Uptime Kuma das Zertifikat überhaupt prüft, einschließlich seines Ablaufdatums.

Backups: ein Verzeichnis

Da sich alles in /app/data befindet, ist ein Backup eine Kopie dieses Volumes, die bei gestopptem Container erstellt wird. Dadurch bleibt die SQLite-Datei konsistent:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

Ermitteln Sie den tatsächlichen Namen des Volumes zuerst mit docker volume ls | grep kuma, da Compose ihm das Projektverzeichnis voranstellt. Kopieren Sie das Tarball anschließend vom Server herunter, denn ein Backup auf derselben VPS ist nur eine Kopie und kein Backup. Die Wiederherstellung erfolgt umgekehrt: Stoppen Sie den Stack, extrahieren Sie die Dateien in ein leeres /app/data-Volume und starten Sie ihn.

Upgrades

Upgrades bestehen aus dem Abruf eines Images:

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

Der neue Container führt beim ersten Start erforderliche Datenbankmigrationen aus. Überwachen Sie dazu docker compose logs -f. Erstellen Sie das obige Backup vor dem Abruf, und bleiben Sie innerhalb eines Major-Tags: Der Wechsel von :1 zu :2 migriert die Datenbank. Laut Migrationsanleitung des Projekts müssen Sie bei einer unterbrochenen Migration das Backup wiederherstellen und den Vorgang erneut ausführen. Erstellen Sie daher zuerst ein Backup und lesen Sie die Migrationsanleitung sowie die Release Notes.

Fehlerbilder und die dabei angezeigten Meldungen

Falscher Status „down“ bei einem Monitor für localhost. Der Monitor wird mit timeout of 48000ms exceeded oder connect ETIMEDOUT rot angezeigt, obwohl der Dienst von Ihrem Laptop aus antwortet. Wenn der Monitor auf denselben Host zeigt, auf dem Uptime Kuma läuft, hat eine hohe CPU- oder Speicherauslastung die Prüfung verhungern lassen, nicht das Zielsystem. Verschieben Sie den Monitor auf eine separate VPS und verwenden Sie den öffentlichen Hostnamen als Ziel.

connect ECONNREFUSED 127.0.0.1:443 (oder ein beliebiger Port). An diesem Port hat kein Dienst gelauscht. Entweder ist der Dienst nicht aktiv, oder Sie haben localhost aus dem Container heraus überwacht. Dort bezeichnet 127.0.0.1 den Container, nicht Ihren Server. Überwachen Sie den öffentlichen Hostnamen statt der Loopback-Adresse.

Invalid login: 535-5.7.8 Username and Password not accepted bei einem E-Mail-Test. Die SMTP-Zugangsdaten sind falsch, oder der Anbieter verlangt ein anwendungsspezifisches Passwort und Sie haben Ihr Kontopasswort verwendet. Erstellen Sie ein App-Passwort und fügen Sie dieses ein.

connect ETIMEDOUT oder queryA ETIMEDOUT <host> bei einem E-Mail-Test. Der Port ist falsch, oder der Anbieter blockiert ausgehendes SMTP. Prüfen Sie, ob 465 oder 587 zur Einstellung für Secure/STARTTLS passt, und testen Sie vom Host aus mit nc -vz smtp.example.com 587. Viele Anbieter blockieren ausgehendes 25. Manche blockieren außerdem die Submission-Ports, bis Sie dies freischalten lassen.

self signed certificate oder unable to verify the first certificate bei einem E-Mail-Test. Ihr SMTP-Server stellt ein Zertifikat bereit, dem Node nicht vertraut. Beheben Sie das Zertifikat des Mailservers, statt die Prüfung zu umgehen.

Dashboard bleibt bei „Connecting...“ hängen, die Konsole zeigt WebSocket connection ... failed. Der Reverse Proxy führt kein Upgrade der WebSocket-Verbindung durch. Fügen Sie unter nginx die Header Upgrade und Connection "upgrade" hinzu, oder verwenden Sie einen Proxy, der diese standardmäßig weiterleitet, etwa Traefik oder Caddy. Das HTML wird geladen, weil es sich um einen normalen HTTP-GET handelt. Nur der Live-Socket benötigt das Upgrade.

Der Monitor für den Zertifikatsablauf warnt nie oder warnt fälschlicherweise. Entweder ist Ignore TLS/SSL Error aktiviert, wodurch die Zertifikatsprüfung deaktiviert wird, oder der Monitor verwendet eine IP-Adresse und liest wegen fehlendem SNI das falsche Zertifikat aus. Dabei wird Hostname/IP does not match certificate's altnames angezeigt. Deaktivieren Sie Ignore TLS/SSL Error und überwachen Sie den Dienst anhand des Hostnamens.

SQLITE_BUSY oder database disk image is malformed in den Logs. Das Volume /app/data liegt auf einem Dateisystem ohne ordnungsgemäße Dateisperren, normalerweise NFS. Verschieben Sie es in ein lokales Docker-Volume und stellen Sie es aus dem Backup wieder her.

FAQ

Wo sollte ich meinen Uptime-Monitor ausführen?

Auf einem anderen Server als den überwachten Systemen, idealerweise bei einem anderen Anbieter oder in einer anderen Region. Der Monitor sollte die Systeme über ihre Hostnamen und das öffentliche Internet erreichen, genauso wie Ihre Benutzer. Wenn der Monitor auf demselben Server wie seine Ziele läuft, fällt er zusammen mit dem Server aus. Ein überlasteter Host kann außerdem für eigentlich funktionierende Dienste den Status „down“ melden. Ein kleiner, separater VPS vermeidet beides.

Wie erhalte ich Benachrichtigungen über Telegram oder per E-Mail?

Fügen Sie den Kanal unter Settings then Notifications hinzu und weisen Sie ihn anschließend jedem Monitor zu. Erstellen Sie für Telegram mit @BotFather einen Bot und lesen Sie chat.id aus https://api.telegram.org/bot<token>/getUpdates aus. Verwenden Sie für E-Mail 465 für SSL oder 587 für STARTTLS. Falls Ihr Anbieter Zwei-Faktor-Authentifizierung verwendet, benötigen Sie ein App-Passwort. Klicken Sie auf Test und prüfen Sie, ob die Nachricht ankommt, bevor Sie sich darauf verlassen.

Kann Uptime Kuma einen Cronjob oder ein Backup-Skript überwachen?

Ja. Dafür gibt es den Monitor Push: Uptime Kuma stellt Ihnen eine URL bereit, die Sie am Ende des Skripts mit curl aufrufen. Dadurch wird der Monitor nur bei erfolgreicher Ausführung ausgelöst. Wenn der Auftrag fehlschlägt oder der Server nicht erreichbar ist, kommt der Heartbeat nicht an. Nach Ablauf des Intervalls erhalten Sie eine Benachrichtigung. Dies ist die einzige zuverlässige Methode, um festzustellen, ob ein geplanter Auftrag tatsächlich ausgeführt wurde, da eine externe Prüfung nicht in den Auftrag hineinsehen kann.

Uptime Kuma oder Zabbix: Was sollte ich einsetzen?

Uptime Kuma beantwortet innerhalb von zehn Minuten und mit sehr geringem Ressourcenbedarf die Fragen „Ist der Dienst von außen erreichbar?“ und „Wurde ich benachrichtigt?“. Zusätzlich stellt es eine Statusseite bereit. Es erfasst jedoch keine detaillierten Metriken wie Trends für CPU, Arbeitsspeicher und Datenträger oder systemweite Schwellenwerte. Dafür ist ein vollständiger Zabbix-Monitoring-Server das umfangreichere, agentenbasierte Werkzeug. Viele Betreiber setzen beide Systeme ein. Sie sind noch unsicher, was Sie überhaupt einsetzen sollten? Unsere Übersicht darüber, was Sie 2026 selbst hosten können ordnet Monitoring in den Gesamtzusammenhang ein.

#uptime-kuma#monitoring#docker#self-hosting#status-page