Zum Inhalt

Keine Benachrichtigung trotz rotem Check

Ein Check steht sichtbar auf CRITICAL oder WARNING, aber niemand hat eine Mail/Push/Slack-Nachricht bekommen. Das UI und der Alarm-Pfad sind entkoppelt — ein roter Check im Frontend heißt nicht automatisch „es wurde benachrichtigt". Gehe die Punkte in dieser Reihenfolge durch.

1. Wartezeit pro Status noch nicht abgelaufen?

Jede Alert-Rule hat vier eigene Wartezeiten (Critical/Warning/No Data/Unknown) — ein Problem muss diese Zeit lang durchgehend bestehen, bevor überhaupt eine Benachrichtigung fällig wird. Ist der Check erst seit kurzem rot, ist „noch keine Mail" oft einfach noch keine Fälligkeit.

Wichtig: Löst sich das Problem auf, bevor die Wartezeit abläuft, wird überhaupt nie benachrichtigt — nicht verspätet, sondern gar nicht. Das ist gewolltes Verhalten (kein Alarm für Ausreißer, die sich von selbst erledigen), fühlt sich beim ersten Mal aber oft wie ein Bug an.

Details: Alert Rules → Wartezeit pro Status.

2. Matcht überhaupt eine Regel?

Eine Alert-Rule filtert auf Tenant/Host/Tag/Profil/Check-Type/Regex. Prüfe:

  • Existiert überhaupt eine aktive (nicht pausierte) Regel, die auf diesen Host/Check zutrifft?
  • Passt der Trigger-Typ (Status/Pattern/Threshold/Anomaly) zum aktuellen Zustand des Checks?
  • Nutze den Test-Button im Regel-Editor — er simuliert einen Treffer und zeigt, welche Hosts/Services betroffen wären und an welche Channels gesendet würde, ohne wirklich zu senden.

Details: Alert Rules.

3. Downtime, Acknowledgement oder akzeptierte Ausnahme aktiv?

Drei Zustände unterdrücken Benachrichtigungen, ohne dass der Check-Status selbst sich ändert:

Zustand Wo sichtbar Wirkung
Downtime violette Wartungs-Pille am Host/Check Alerts komplett unterdrückt, solange die Downtime aktiv ist
Acknowledged (ACK) „In Arbeit"-Pille Unterdrückt weitere Eskalation für diese Episode
Akzeptierte Ausnahme ACK ohne „ist ein Problem" Zählt nicht als Problem, alarmiert grundsätzlich nicht

Ein wichtiger Unterschied: „In Arbeit" (ACK mit „ist ein Problem") hält den Check weiterhin als offenes Problem in Health-Score und Rollups, unterdrückt aber die aktive Eskalation. Wird ein akzeptierter oder acked Check schlimmer als zum ACK-Zeitpunkt, bricht die Markierung automatisch — der Check wird wieder ein echtes, alarmierbares Problem.

Details: Acknowledgements, Downtimes.

4. Unterdrückt der Eltern-Host (Inhibition)?

Hängt der betroffene Check an einem Host, der selbst als „nicht erreichbar" gilt (Dependency), unterdrückt Vesana bewusst die Alarme der abhängigen Checks — sonst bekommst du bei einem toten Switch 40 Einzelalarme für jeden dahinter hängenden Host statt einem.

Prüfe im Host-Header den Abhängigkeits-Chip („hängt an: …"). Zeigt er einen Warnzustand, ist das der Grund für die ausbleibende Benachrichtigung — nicht ein Fehler in der Regel selbst.

Details: Dependencies & Inhibition.

5. Neue oder reaktivierte Regel — Anti-Blast

Legst du eine neue Regel an oder reaktivierst eine pausierte Regel, während irgendwo schon seit Stunden ein Problem läuft, zählt die Wartezeit dieser Regel erst ab der Erstellung/Reaktivierung — nicht rückwirkend ab dem tatsächlichen Beginn des Problems. Das ist Absicht (eine frisch gespeicherte Regel soll nicht sofort eine Flut an Benachrichtigungen über alles bereits Laufende auslösen), erklärt aber, warum ein länger schon rotes Problem nach dem Anlegen einer passenden Regel nicht sofort eine Mail auslöst.

6. Kanal selbst funktionsfähig?

Auch wenn Regel und Timing stimmen: der Channel selbst kann kaputt sein.

  • Test-Funktion je Channel nutzen (Notification Channels → Channel → Test) — sendet eine Test-Nachricht ohne echten Alarm.
  • SMTP falsch konfiguriert? Prüfe SMTP-Integration.
  • Webhook-Endpoint down oder Auth falsch? Prüfe Webhooks.
  • Severity-Filter im Channel zu restriktiv (z. B. nur „CRIT", aber der Check ist „WARNING")?
  • Mobile-Push: prüft nur einen tatsächlich in der Regel gematchten mobile_push-Channel inkl. dessen Mindest-Schweregrad — ein Channel, der in der Regel nicht enthalten ist, sendet nichts.

Details: Notification Channels.

7. Recovery-Notification bekommen, aber nie den ursprünglichen Alarm?

Recovery-Meldungen gehen an genau die Channels, die beim ursprünglichen Alarm tatsächlich benachrichtigt wurden — nicht an die aktuell konfigurierten Channels der Regel. Wurde die Regel zwischen Alarm und Recovery geändert (z. B. ein Channel entfernt), bekommt trotzdem der ursprüngliche Channel die Recovery-Mail. Umgekehrt: ein neu hinzugefügter Channel bekommt keine Recovery-Mail für einen Alarm, der vor seiner Hinzufügung ausgelöst hat.

Schnell-Checkliste

  • [ ] Wartezeit für diesen Status abgelaufen?
  • [ ] Test-Button zeigt einen Treffer?
  • [ ] Keine Downtime/ACK/Ausnahme aktiv?
  • [ ] Eltern-Host nicht als „nicht erreichbar" markiert?
  • [ ] Regel nicht gerade erst angelegt/reaktiviert, während das Problem schon lief?
  • [ ] Channel-Test erfolgreich?

Anschluss