Uptime Kuma selbst hosten: Monitoring für Websites, Ports und Zertifikate

Der unangenehmste Weg, von einem Ausfall zu erfahren, ist der Anruf eines Kunden. Der zweitunangenehmste ist ein abgelaufenes TLS-Zertifikat, das die Website an einem Sonntagmorgen mit einer Browser-Warnung begrüßt. Beides lässt sich mit einem Werkzeug abfangen, das in einer halben Stunde steht: Uptime Kuma.

Was das Tool abdeckt

Uptime Kuma ist ein selbst gehostetes Monitoring mit Weboberfläche. Es prüft Endpunkte in einstellbaren Intervallen und schlägt Alarm, wenn etwas nicht stimmt. Die Monitor-Typen decken den Alltag weitgehend ab:

• HTTP(s) — Statuscode, Antwortzeit, optional mit Basic Auth oder eigenen Headern
• HTTP(s) Keyword — prüft zusätzlich, ob ein Text im Body vorkommt. Fängt die Fälle, in denen der Server brav 200 liefert, die Seite aber eine leere Fehlerhülle ist
• TCP Port — für Dienste ohne HTTP: Datenbanken, SMTP, SSH
• Ping — erreichbar oder nicht, ohne Applikationsebene
• DNS — löst ein Record noch auf den erwarteten Wert auf
• Docker Container — Zustand eines Containers über den Docker-Socket

Der Punkt, der in der Praxis am häufigsten etwas rettet, kommt bei HTTPS-Monitoren gratis dazu: Uptime Kuma liest die Restlaufzeit des TLS-Zertifikats aus und meldet sich, bevor es abläuft. Die Vorwarnzeiten sind pro Benachrichtigung einstellbar — mehrere Stufen, typischerweise drei Wochen, zwei Wochen und eine Woche vorher, sind sinnvoll. Auch mit funktionierendem cert-manager lohnt sich das: Der Alarm meldet nicht, dass die Erneuerung ansteht, sondern dass sie ausgeblieben ist.

Variante 1: Docker Compose

Für einen einzelnen Server oder eine kleine Umgebung reicht Compose:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data
      # Nur wenn Docker-Container überwacht werden sollen. Der Socket gibt
      # vollen Zugriff auf den Docker-Daemon — weglassen, wenn nicht gebraucht.
      # - /var/run/docker.sock:/var/run/docker.sock:ro

docker compose up -d, dann Port 3001 im Browser öffnen und den Admin-Account anlegen. Der erste Aufruf legt ihn ohne weitere Prüfung an — die Instanz sollte also nicht offen im Netz stehen, bevor dieser Schritt erledigt ist.

Alles Wichtige liegt in /app/data: die SQLite-Datenbank, die Konfiguration und die Historie. Genau dieses Verzeichnis gehört ins Backup, alles andere ist aus dem Image reproduzierbar.

Variante 2: Kubernetes

Im Cluster sind drei Punkte entscheidend, an denen ein naiv übernommenes Standard-Deployment scheitert.

Eine Replica, kein Rolling Update. Die Datenbank ist SQLite in einem Volume. Zwei Pods auf derselben Datei bedeuten Korruption. Also replicas: 1 und die Strategie Recreate, damit beim Update nicht kurzzeitig zwei Pods laufen.

ReadWriteOnce reicht — mehr braucht es bei einer Replica nicht, und die meisten Block-Storage-Klassen bieten ohnehin nichts anderes.

WebSockets müssen durch. Die Oberfläche aktualisiert sich live über Socket.IO. Traefik und die meisten Ingress-Controller machen das ohne Zusatzkonfiguration, andere brauchen einen expliziten Hinweis.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uptime-kuma-data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: uptime-kuma
spec:
  replicas: 1
  # SQLite in einem RWO-Volume: niemals zwei Pods gleichzeitig.
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: uptime-kuma
  template:
    metadata:
      labels:
        app: uptime-kuma
    spec:
      containers:
        - name: uptime-kuma
          image: louislam/uptime-kuma:1
          ports:
            - name: http
              containerPort: 3001
          volumeMounts:
            - name: data
              mountPath: /app/data
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 30
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 10
          resources:
            requests:
              cpu: 50m
              memory: 192Mi
            limits:
              memory: 512Mi
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: uptime-kuma-data
---
apiVersion: v1
kind: Service
metadata:
  name: uptime-kuma
spec:
  selector:
    app: uptime-kuma
  ports:
    - name: http
      port: 80
      targetPort: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: uptime-kuma
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: traefik
  rules:
    - host: status.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: uptime-kuma
                port:
                  name: http
  tls:
    - secretName: uptime-kuma-tls
      hosts:
        - status.example.com

Ein Hinweis zum Speicherlimit: Uptime Kuma ist eine Node.js-Anwendung, und ein zu knapp gesetztes Limit äußert sich nicht als sauberer Fehler, sondern als stiller OOM-Kill mitten in der Nacht. 512 MiB sind für einige Dutzend Monitore eine ruhige Größe.

Benachrichtigungen

Ein Monitor ohne Benachrichtigung ist ein Dashboard, das niemand ansieht. Die Kanäle werden unter Settings → Notifications angelegt und lassen sich anschließend mehreren Monitoren zuweisen — oder per Häkchen als Standard für alle neuen.

Discord ist der schnellste Weg: Im Zielkanal unter Integrationen → Webhooks eine Webhook-URL erzeugen, in Uptime Kuma als Typ „Discord“ eintragen, fertig. Ein Bot-Name lässt sich optional setzen.

Google Chat funktioniert analog. Im Space über Apps & Integrationen → Webhooks eine eingehende Webhook-URL anlegen und als Typ „Google Chat (Google Workspace)“ hinterlegen. Wichtig: Eingehende Webhooks stehen nur in Spaces zur Verfügung, nicht in Direktnachrichten, und die Workspace-Administration kann sie sperren.

Microsoft Teams ist der Kanal mit dem meisten Bewegtteil. Microsoft hat die klassischen Office-365-Connector-Webhooks als veraltet eingestuft; neue Integrationen laufen über Power-Automate-Workflows („Post to a channel when a webhook request is received“), die ebenfalls eine URL liefern. Uptime Kuma führt beide Wege als eigene Benachrichtigungstypen. Prüfen Sie in Ihrer Version, welcher angeboten wird, und richten Sie neue Alarme direkt über den Workflow-Weg ein — ein Connector, der irgendwann still abgeschaltet wird, ist schlimmer als gar kein Alarm.

Für den Ernstfall lohnt sich eine zweite, unabhängige Strecke: Chat-Plattformen fallen selbst aus, und ein Alarm über denselben Kanal wie der Ausfall erreicht niemanden. Eine E-Mail-Benachrichtigung über einen externen SMTP-Anbieter oder eine Signal-/Telegram-Anbindung ist als Rückfallebene schnell ergänzt.

Fehlalarme dämpfen: Stellen Sie „Retries“ auf 2 bis 3 und ein kurzes Retry-Intervall ein. Damit löst ein einzelner Paketverlust keinen Alarm aus, ein echter Ausfall aber nach wenigen Sekunden. „Resend every X times“ schickt Erinnerungen, solange ein Dienst unten bleibt — sonst geht die einzelne Meldung im Chatverlauf unter.

Status-Seiten und Wartungsfenster

Zwei Funktionen, die im Kundengeschäft mehr wert sind, als es zunächst klingt:

Status-Seiten bündeln ausgewählte Monitore unter einer eigenen Domain, öffentlich oder passwortgeschützt. Statt Rückfragen zu beantworten, verweist man auf eine Seite, die den aktuellen Zustand selbst zeigt.

Wartungsfenster unterdrücken Alarme in geplanten Zeiträumen — einmalig oder wiederkehrend. Ohne sie gewöhnt sich das Team an, Meldungen wegzuklicken, und genau dann geht die echte unter.

Die eine Sache, die oft übersehen wird

Monitoring, das im selben Cluster läuft wie die überwachte Anwendung, hat einen blinden Fleck: Fällt der Cluster aus, fällt auch die Überwachung aus — und schweigt. Der Ausfall sieht dann aus wie Ruhe.

Die saubere Antwort ist eine zweite, kleine Instanz außerhalb: ein günstiger VPS bei einem anderen Anbieter, der ausschließlich die Erreichbarkeit von außen prüft. Die große Instanz im Cluster übernimmt die Tiefe — interne Dienste, Datenbanken, Container. Die kleine externe beantwortet die eine Frage, die im Ernstfall zählt: Kommt ein Besucher noch auf die Seite?

Ergänzend gehört Uptime Kuma selbst überwacht. Ein „Push“-Monitor, den ein Cronjob von außen anstößt, oder schlicht der gegenseitige Blick der beiden Instanzen aufeinander genügt.

Fazit

Uptime Kuma ersetzt kein Prometheus mit Grafana — es beantwortet eine andere Frage. Prometheus zeigt, wie es einem System innerlich geht. Uptime Kuma zeigt, ob es von außen noch da ist, und meldet sich, bevor ein Zertifikat abläuft. Für diesen Zweck ist der Aufwand kaum zu unterbieten: ein Container, ein Volume, ein paar Webhooks.

Wir richten Monitoring für Kundensysteme ein und betreiben es mit — inklusive Alarmierung, die im Ernstfall auch jemanden erreicht. Sprechen Sie uns an.