Uptime Kuma selbst hosten für Statusseiten und Alerts

Du willst wissen, wann deine Site, API oder dein Server ausfällt, und du willst eine Statusseite, auf die du Kunden verweisen kannst, ohne eine monatliche Gebühr für etwas zu zahlen, das ein einzelner Container kann. Uptime Kuma ist ein Open-Source-Monitoring-Tool, das beides macht: Es pingt deine Endpunkte nach Zeitplan, schickt dir im Moment eines Ausfalls einen Alert und gibt dir eine öffentliche Statusseite, um das Ergebnis zu zeigen. Am Ende hast du es auf deinem eigenen Server laufen, über HTTPS auf deiner eigenen Domain erreichbar, mit Daten, die einen Neustart tatsächlich überleben.

Was du brauchst

• Einen kleinen Server. Uptime Kuma ist ein einzelner Node.js-Prozess mit einer SQLite-Datenbank, braucht also nicht viel, aber mindestens 1 GB RAM zu geben, vermeidet die im Troubleshooting-Abschnitt unten beschriebenen Out-of-Memory-Probleme. Ein DigitalOcean Basic Droplet mit 1 GB RAM, 1 vCPU und 25 GB SSD kostet 6 $/Monat Stand heute (geprüft gegen DigitalOceans eigene Preisseite). Hetzners kostenoptimierte Linie ist eine vernünftige Alternative, falls du lieber vergleichen willst.
• Eine Domain, die du kontrollierst, mit der Möglichkeit, einen A-Record hinzuzufügen.
• Docker und Docker Compose auf dem Server installiert (Schritt 2 deckt das ab).
• Ein paar Minuten beim ersten Besuch, um den Admin-Account zu erstellen. Uptime Kuma kommt ohne Standard-Login: Wer auch immer zuerst auf die Setup-Seite kommt, wird zum Admin, also lass sie nicht offen für das Internet, bevor dieser Schritt erledigt ist.

Schritt 1: Domain auf den Server zeigen lassen

Erstelle zuerst den Server, merke dir seine öffentliche IP-Adresse und füge dann einen A-Record für die Subdomain hinzu, die du nutzen willst, zum Beispiel status.yourdomain.com, der auf diese IP zeigt. DNS-Propagation ist meist schnell, kann aber je nach TTL-Einstellungen deines Registrars bis zu ein paar Stunden dauern.

Du kannst prüfen, ob es aufgelöst wurde, mit:

dig +short status.yourdomain.com

Du solltest die IP-Adresse des Servers zurückbekommen. Kommt noch nichts zurück, warte etwas, bevor du weitermachst. Diesen Schritt zuerst zu machen heißt, dass DNS Zeit hatte, sich zu setzen, bis du später bei HTTPS ankommst.

Schritt 2: Docker installieren

Uptime Kumas eigene Installationsdoku empfiehlt, es als Container zu betreiben, und das ist das Setup, das dieser Beitrag durchgehend nutzt. Verbinde dich per SSH mit deinem Server und installiere Docker mit dem offiziellen Convenience-Skript:

curl -fsSL https://get.docker.com | sh

Docker Compose kommt bei aktuellen Docker-Installationen als Plugin mit, also ist meist kein separater Installationsschritt nötig. Bestätige, dass beide vorhanden sind:

docker --version
docker compose version

Du solltest für jedes eine Versionsnummer ausgegeben sehen. Falls docker compose version fehlschlägt, ist deine Docker-Installation alt genug, dass Compose nicht mitgeliefert wird, und du musst das Paket docker-compose-plugin separat installieren.

Schritt 3: Compose-Datei schreiben und Uptime Kuma starten

Erstelle ein Verzeichnis für die App und darin eine compose.yml:

mkdir -p ~/uptime-kuma && cd ~/uptime-kuma

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

volumes:
  uptime-kuma-data:

Der Tag 1 folgt der aktuellen stabilen Release-Linie und aktualisiert sich mit Patch-Releases, wenn du erneut ziehst, statt einen exakten Build zu fixieren. Der wichtige Teil ist das benannte Volume uptime-kuma-data, gemountet unter /app/data: Dort hält Uptime Kuma seine SQLite-Datenbank, und das ist es, was deine Monitore, Benachrichtigungseinstellungen und Statusseiten einen Container-Neustart oder -Rebuild überleben lässt. Überspringst du das Volume, löscht ein docker compose down oder ein Server-Reboot, der den Container neu erstellt, jeden Monitor, den du eingerichtet hast.

Starte es:

docker compose up -d

Prüfe, ob es läuft:

docker compose ps

Du solltest den uptime-kuma-Dienst als running oder healthy aufgelistet sehen. An diesem Punkt ist er nur über Port 3001 erreichbar, was in Ordnung ist, da Schritt 5 einen Reverse Proxy davor setzt.

Schritt 4: Admin-Account erstellen und deinen ersten Monitor hinzufügen

Bevor DNS und HTTPS eingerichtet sind, kannst du die App trotzdem direkt über ihren Port erreichen, um den Admin-Account zu erstellen, was das Zeitfenster der offenen Setup-Seite so früh wie möglich schließt:

http://<server-ip>:3001

Der erste Bildschirm fragt dich nach einem Benutzernamen und Passwort. Es gibt keinen Standard-Login zu ändern, nur eine leere Fläche. Sobald du drin bist, füge vom Dashboard aus einen Monitor hinzu: gib ihm einen Namen, einen Typ (HTTP(s), TCP-Port, Ping, DNS und andere werden unterstützt) und das zu prüfende Ziel. Setze das Prüfintervall (60 Sekunden ist für die meisten Sites ein vernünftiger Standard) und speichere ihn.

Während du dort bist, geh zu Settings → Notifications und füge mindestens einen Benachrichtigungskanal hinzu (E-Mail, Slack, Discord, ein generischer Webhook und Dutzende andere werden unterstützt). Nutze den Test-Button bei der Benachrichtigung, bevor du dich darauf verlässt: eine falsch konfigurierte Webhook-URL oder ein E-Mail-Provider, der die Nachricht still abweist, ist der häufigste Weg, auf dem Leute während eines echten Ausfalls entdecken, dass ihre Alerts nie wirklich zugestellt wurden.

Du solltest den Status deines neuen Monitors innerhalb eines Prüfintervalls grün werden sehen (oder rot, falls du ihn auf etwas Unerreichbares gerichtet hast).

Schritt 5: Caddy davorsetzen für HTTPS

Ein Monitoring-Dashboard auf einem blanken HTTP-Port zu betreiben, ohne Zertifikat und ohne Domain, ist für Tests in Ordnung, aber nicht für etwas, auf das du dich wirklich verlässt. Caddy ist ein Reverse Proxy, der automatisch ein Let’s-Encrypt-Zertifikat anfordert und erneuert, ohne separates Certbot-Setup.

Installiere Caddy direkt auf dem Server (außerhalb der Compose-Datei, damit es sauber an die Ports 80 und 443 binden kann):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Ersetze /etc/caddy/Caddyfile durch:

status.yourdomain.com {
	reverse_proxy localhost:3001
}

Lade Caddy neu, damit die Änderung übernommen wird:

sudo systemctl reload caddy

Caddy fordert das Zertifikat beim ersten Request für diesen Hostnamen an, was nur gelingt, wenn der A-Record aus Schritt 1 schon auf diesen Server aufgelöst wird. Du solltest sehen, dass https://status.yourdomain.com Uptime Kuma mit einem gültigen Schloss lädt, und einfache http://-Requests an denselben Hostnamen sollten automatisch auf HTTPS umleiten. Sobald das funktioniert, sperre den direkten Zugriff auf Port 3001 in deiner Firewall, damit die App nur über Caddy erreichbar ist.

Schritt 6: Datenvolume sichern

Alles, was zählt (Monitore, Benachrichtigungseinstellungen, Statusseiten-Konfiguration, Historie), lebt in der SQLite-Datei im uptime-kuma-data-Volume. Sichere es nach Zeitplan, statt erst während eines echten Vorfalls festzustellen, dass du es brauchst.

Ein einfacher, cron-freundlicher Ansatz, vom Host ausgeführt:

docker run --rm \
  -v uptime-kuma_uptime-kuma-data:/data \
  -v ~/uptime-kuma-backups:/backup \
  alpine tar czf /backup/uptime-kuma-$(date +%F).tar.gz -C /data .

Füge das als täglichen Cron-Job hinzu (crontab -e) und behalte die letzten ein, zwei Wochen Archive. Du solltest eine neue .tar.gz-Datei in ~/uptime-kuma-backups landen sehen, nachdem es läuft. Um wiederherzustellen, stoppe den Container, extrahiere das Archiv zurück in denselben Volume-Pfad und starte ihn wieder.

Schritt 7: Später upgraden

Da die Compose-Datei den rollenden 1-Tag statt einer exakten Patch-Version fixiert, holt ein erneutes Ziehen das neueste Patch-Release dieser Linie:

docker compose pull
docker compose up -d

Docker erstellt den Container mit dem neuen Image neu, lässt das benannte Volume aber unberührt, sodass deine Daten nicht betroffen sind. Prüfe speziell vor einem Major-Version-Sprung die Release Notes auf Uptime Kumas GitHub-Releases-Seite, da diese Breaking Changes enthalten können, die ein Patch-Release nicht hätte.

Der Shortcut: mit Railyard

Alles oben ist der komplette manuelle Weg, und es ist eine vernünftige Art, das zu betreiben, wenn du jeden Teil davon selbst besitzen willst. Falls du lieber die Server-Provisionierung, Docker-Installation, Compose-Datei und Reverse-Proxy-Konfiguration überspringst und dieselbe laufende App bekommst: Railyards Uptime-Kuma-Vorlage deployt dasselbe Image mit dem Datenvolume schon unter /app/data gemountet und HTTPS schon erledigt. Es gibt nichts zu konfigurieren, nachdem es deployed ist: kein Standard-Login in beiden Fällen, du erstellst den Admin-Account bei deinem ersten Besuch, genauso wie im manuellen Weg. Es ist dieselbe App, derselbe Einrichtungsschritt, nur ohne die Serververwaltung dazwischen.

Falls du generell neu bei Railyard bist, decken der Quickstart und Deployen mit einem Ein-Klick-Button die Grundlagen ab, und Hosting-Kosten schlüsselt auf, was eine kleine App wie diese üblicherweise bei verschiedenen Providern kostet.

Troubleshooting

„Bind for 0.0.0.0:3001 failed: port is already allocated”. Etwas anderes auf dem Server nutzt bereits Port 3001, oft ein vorheriger Versuch, den Container laufen zu lassen, der nicht entfernt wurde. Prüfe mit docker ps -a und entferne den veralteten Container, oder ändere die Host-Seite des Port-Mappings in compose.yml (zum Beispiel "3002:3001") und aktualisiere das Caddy-Reverse-Proxy-Ziel entsprechend.

Caddy stellt kein Zertifikat aus. Das ist fast immer DNS, nicht Caddy. Wenn der A-Record aus Schritt 1 noch nicht propagiert ist oder auf die falsche IP zeigt, erreicht Let’s Encrypts Validierungsanfrage deinen Server nie, und die Zertifikatsanfrage scheitert still in den Caddy-Logs (sudo journalctl -u caddy -n 50). Führe den dig-Befehl aus Schritt 1 erneut aus, um zu bestätigen, dass der Record zur richtigen IP aufgelöst wird, bevor du etwas anderes untersuchst.

Monitore sind nach einem Neustart oder Redeploy verschwunden. Das bedeutet, der Container lief ohne das benannte Volume, oder mit dem Volume am falschen Pfad gemountet. /app/data ist der einzige Pfad, in den Uptime Kuma seine Datenbank schreibt. Falls du schnell ein docker run ohne -v zum Testen ausgeführt hast, sind die Daten dieses Containers weg, sobald er entfernt wird. Prüfe doppelt, dass docker volume ls uptime-kuma_uptime-kuma-data zeigt und dass es dasjenige ist, das in deiner Compose-Datei gemountet ist.

Benachrichtigungen kommen tatsächlich nicht an. Uptime Kuma loggt einen fehlgeschlagenen Benachrichtigungsversand in seinem eigenen Event-Log, aber es ist leicht zu übersehen, wenn du nicht danach suchst. Nutze immer den Test-Button in Settings → Notifications direkt nach dem Hinzufügen eines Kanals, nicht nur, als du zum ersten Mal einen Monitor eingerichtet hast. Leicht falsche Webhook-URLs, E-Mail-Provider, die ein App-Passwort statt deines normalen brauchen, und abgelaufene Slack-Tokens sind die häufigsten Ursachen.

Der Container startet auf einem sehr kleinen Server ständig neu. Auf einem 512-MB-Droplet kann Uptime Kumas Node.js-Prozess unter Last OOM-gekillt werden, besonders wenn du viele Monitore mit kurzen Prüfintervallen hinzufügst oder Monitore aktivierst, die einen Headless-Browser nutzen. dmesg | grep -i "out of memory" bestätigt es. Die Lösung ist mehr RAM, nicht mehr Tuning: ein 1-GB-Plan ist das realistische Minimum für einen komfortablen, wartungsarmen Betrieb.

FAQ

Ist Uptime Kuma kostenlos? Ja, es ist Open Source (MIT-lizenziert) und selbst gehostet, es gibt also kein Abonnement. Du zahlst nur für den Server, auf dem es läuft.

Brauche ich eine Datenbank? Nein. Uptime Kuma nutzt eine eingebettete SQLite-Datenbank innerhalb seines eigenen Datenvolumes, es gibt also nichts Zusätzliches zu provisionieren oder zu verbinden.

Kann ich mehr als eine Site oder einen Server von einer einzelnen Instanz aus überwachen? Ja, eine einzelne Uptime-Kuma-Instanz kann beliebig viele Monitore betreiben, jeder unabhängig nach seinem eigenen Zeitplan und Typ geprüft.

Ist die Statusseite standardmäßig öffentlich? Statusseiten sind etwas, das du bewusst im Dashboard erstellst und veröffentlichst. Einzelne Monitore sind nicht exponiert, bis du sie zu einer Statusseite hinzufügst, die du bewusst öffentlich machst.

Wie unterscheidet sich das von UptimeRobot oder Pingdom? Das sind gehostete Dienste, für die du monatlich zahlst und deren Infrastruktur du nicht kontrollierst. Uptime Kuma gibt dir denselben Kernfunktionsumfang (HTTP/TCP/Ping-Checks, Alerting, öffentliche Statusseiten), der auf einem Server läuft, den du besitzt, mit deiner Monitoring-Historie in deiner eigenen Datenbank statt der eines Anbieters.

Sobald es läuft und gesichert ist, ist das eines der wartungsärmsten Dinge, die du selbst hosten kannst: Es checkt alles andere für dich, und es verlangt nur etwas von dir, wenn tatsächlich etwas nicht stimmt.