Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

Schwierigkeit: Leicht · Dauer: 30–50 Min · Ziel: Uptime-Kuma-Checks und Benachrichtigungen so konfigurieren, dass echte Störungen schnell sichtbar werden.

Kurzproblem und Zielbild

Zu aggressive Monitoring-Defaults erzeugen Alarmrauschen. Ziel ist ein stabiles Signal-Rausch-Verhältnis mit klaren Intervallen, Timeouts und sauberen Notification-Profilen.

Voraussetzungen

• Laufende Uptime-Kuma-Instanz
• Mindestens ein Notification-Channel (Mail/Discord/Telegram)
• Liste kritischer Dienste

Schnellstart (funktionierende Basis)

docker ps | grep uptime-kuma
# UI öffnen und 3 kritische Monitore anlegen
# Intervall 60s, Retry 2, Timeout 16s

Schritt-für-Schritt Umsetzung

1) Monitore nach Kritikalität gruppieren

# Kritisch: Auth, Reverse Proxy, DNS
# Wichtig: Medien/Tools
# Nice-to-have: Nebenservices

2) Timeouts/Retry je Diensttyp

# HTTP intern: timeout 10-16s
# Extern über WAN: timeout 20-30s
# retry sparsam nutzen, sonst Alarmflut

3) Wartungsfenster definieren

# Geplante Updates als Maintenance in Kuma eintragen

4) Alert-Routing trennen

# Kritisch -> sofort Push
# Nicht-kritisch -> gesammelt / zeitversetzt

Validierung / Checks

# 1) Kuma-Container und Health prüfen
docker ps --filter name=uptime-kuma
curl -fsS http://127.0.0.1:3001 >/dev/null && echo "Kuma UI erreichbar"

# 2) Gezielten Ausfall simulieren (Beispielservice)
docker stop reverse-proxy
sleep 90

# 3) Prüfen: genau 1 Alert + Recovery nach Wiederanlauf
docker start reverse-proxy
sleep 90

# 4) Kuma-Logs auf Flapping/Fehler prüfen
docker logs --since 10m uptime-kuma | tail -n 120

Troubleshooting

Zu viele Fehlalarme

# DNS/Latenz prüfen
dig +short example.local
ping -c 4 example.local

# Host-Antwortzeit testen
curl -o /dev/null -s -w "HTTP:%{http_code} TIME:%{time_total}\n" https://example.local

# Danach in Kuma: Timeout +5s, Retry -1

Recovery-Meldung fehlt

# Notification-Test in Kuma auslösen
# Settings -> Notifications -> Test

# Container-Logs nach Sendefehlern durchsuchen
docker logs --since 30m uptime-kuma | grep -Ei "notify|telegram|discord|smtp|error" | tail -n 80

Fazit

Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

Quellen

• Uptime Kuma Repository
• Uptime Kuma Wiki
• SRE Workbook – Monitoring