Von Matt Connor 2026-07-15 · Aktualisiert 2026-08-25

Uptime Kuma selbst hosten: Websites und Server überwachen

Q: 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 /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.

Q: 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.

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 benachrichtigt Sie per E-Mail, Telegram, Discord oder über einen Webhook, sobald einer dieser Dienste nicht mehr antwortet. Uptime Kuma besteht aus einem Node-Prozess und einer SQLite-Datei. Daher läuft es problemlos mit 256-512 MB RAM und bietet ein Live-Dashboard, Verlaufsdiagramme sowie eine öffentliche Statusseite. Die Installation besteht aus einer Compose-Datei mit zehn Zeilen. Entscheidend ist jedoch, wo Sie den Container betreiben und ob Ihre Benachrichtigungen jemals bei einem Test 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 von Schutz, während er in Wirklichkeit 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 bewusst so festgelegt.

127.0.0.1:3001:3001 statt 3001:3001. Docker veröffentlicht Ports mit DNAT-Regeln, die ausgewertet werden, bevor ufw das Paket verarbeitet. Ein einfaches 3001:3001 stellt Ihr Dashboard daher unabhängig von Ihrer Firewall ins öffentliche Internet. Durch die Bindung an das Loopback-Interface bleibt es privat, während nur der Reverse Proxy erreichbar ist. Eine private Instanz kann den Proxy überspringen und 3001 über ein selbst gehostetes WireGuard-VPN erreichen.

Ein benanntes Volume unter /app/data. Dort liegen alle Daten, die Uptime Kuma speichert: die SQLite-Datenbank, Ihre Monitore, Benachrichtigungseinstellungen und Logos für Statusseiten. Wenn Sie dieses Volume verlieren, wird die Administrationsoberfläche leer neu eingerichtet. Es ist das einzige Element, das Sie sichern müssen.

Das Image ist auf einen Major-Tag, :2, festgelegt. Dies ist die aktuelle stabile Versionslinie. Prüfen Sie vor dem Kopieren auf Docker Hub, ob es eine neuere Hauptversion gibt. Verwenden Sie niemals einen veränderlichen Tag wie latest, den das Projekt abkündigt. Ein Sprung auf eine neue Hauptversion führt bei diesem Image zu einer irreversiblen Datenbankmigration. Diese Migration sollten Sie gezielt auslösen und nicht bei einem routinemäßigen Pull unerwartet starten.

Ein wichtiger Hinweis: /app/data muss auf einem Dateisystem mit POSIX-Dateisperren liegen. Ein lokales Docker-Volume ist geeignet. Bei NFS wird die SQLite-Datenbank beschädigt und Sie erhalten SQLITE_BUSY und 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 auf oder verwenden Sie einen SSH-Tunnel: Führen Sie ssh -L 3001:127.0.0.1:3001 user@your-vps aus und öffnen Sie http://localhost:3001. Auf der ersten Seite werden der Benutzername und das Passwort des Administrators eingerichtet. Es gibt keinen Standard-Login. Wählen Sie ein sicheres Passwort. Dieses Dashboard zeigt 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 Benachrichtigungen ein, bevor Sie Monitore hinzufügen. Dadurch können Sie beim Erstellen jedes Monitors einen Kanal zuweisen. Öffnen Sie Settings then Notifications then Setup Notification. Verwenden Sie die Schaltfläche Test jedes Kanals, um zu bestätigen, dass die Nachricht ankommt. Eine ungetestete Benachrichtigung ist die zweithäufigste Ursache für einen unbemerkt fehlschlagenden Setup.

E-Mail (SMTP). Tragen Sie Host, Port, Verschlüsselung, Benutzernamen, Passwort sowie einen From- und einen To-Wert ein. Die beiden funktionierenden Kombinationen sind 465 mit der Einstellung "Secure" auf TLS/SSL oder 587 mit STARTTLS. Für Gmail und die meisten Anbieter mit Zwei-Faktor-Authentifizierung müssen Sie ein App-Passwort erzeugen. Ein normales Kontopasswort führt zu Error: Invalid login: 535-5.7.8 Username and Password not accepted.

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

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.

Generischer Webhook. Für alle anderen Ziele, beispielsweise 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 enthaltene Apprise-Integration unterstützt die meisten der rund 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 Benachrichtigungen über einen Kanal, den Sie vollständig selbst kontrollieren, 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.

Vor einen Reverse Proxy mit TLS schalten und WebSockets berücksichtigen

Für eine öffentlich erreichbare Instanz schalten Sie für TLS und einen Hostnamen einen Reverse Proxy vor den an die Loopback-Adresse gebundenen Container. Der entscheidende Punkt, an dem es häufig zu Problemen kommt: Die Oberfläche von Uptime Kuma ist eine Live-Socket.IO-Anwendung. Der Proxy muss die WebSocket-Verbindung upgraden. Fehlt diese Konfiguration, wird die Seite geladen, aber keine Verbindung hergestellt. Das Dashboard bleibt bei „Connecting...“, 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 Anfragen an den Loopback-Port weiterleitet. Konfigurieren Sie ihn zunächst für Port 80. Lassen Sie certbot danach TLS hinzufügen. Die Challenge, der Timer für die Erneuerung und die entsprechenden Fehlerfälle werden unter Let's-Encrypt-Zertifikate mit certbot und nginx ausstellen beschrieben.

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 certbot anschließend den Block so anpassen, dass er auf Port 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 Direktiven 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 HTTP-Basisauthentifizierung. Dadurch würden auch die öffentliche Statusseite und der Endpunkt /api/push gesperrt. 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 ein VPN darauf zu.

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 alle erforderlichen Datenbankmigrationen aus. Überwachen Sie docker compose logs -f. Erstellen Sie die oben beschriebene Sicherung vor dem Abruf, und bleiben Sie innerhalb eines Major-Tags: Der Wechsel von :1 zu :2 ist eine Migration in nur eine Richtung. Erstellen Sie daher zuerst eine Sicherung und prüfen Sie 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