Warum der Kanal so wichtig ist wie der Alert selbst
Ein Alert, der über den falschen Kanal zugestellt wird, kann genauso schädlich sein wie kein Alert – oder im schlimmsten Fall schlimmer. Wer nachts um 3 Uhr einen Slack-Kanal auf stumm geschaltet hat, bekommt eine kritische Benachrichtigung nicht mit. Wer tagsüber in Meetings versunken ist, reagiert auf eine Push-Benachrichtigung womöglich zu spät. Und wer bei jedem kleinen Monitoring-Event per Anruf geweckt wird, schaltet das Telefon irgendwann auf lautlos.
Bildquelle: Pexels (Pexels License – kostenlose Nutzung)
Eine durchdachte Kanalstrategie legt fest, welches Kommunikationsmittel bei welchem Schweregrad und welcher Situation zum Einsatz kommt. Sie ist die Grundlage dafür, dass kritische Incidents schnell die richtigen Personen erreichen – und gleichzeitig Alert-Fatigue durch unnötige Unterbrechungen verhindert wird.
Die wichtigsten Alert-Kanäle und ihre Stärken
Telefonanruf – für kritische, zeitkritische Incidents
Ein Anruf ist der einzige Kanal, der Menschen in fast jeder Situation unterbricht: mitten in der Nacht, in einer Besprechung, beim Sport. Genau deshalb sollte er ausschließlich für Incidents reserviert sein, bei denen eine sofortige Reaktion innerhalb von Minuten erforderlich ist – typischerweise P1-Incidents mit direktem Business-Impact oder Sicherheitsvorfälle mit aktivem Angriffsvektor.
Telefonanrufe als einzige Reaktion auf jeden Alert zu nutzen, ist ein sicherer Weg in die Alert-Fatigue. Sobald On-Call-Personen lernen, dass ein Anruf nicht unbedingt etwas Kritisches bedeutet, reagieren sie langsamer oder stellen das Telefon auf lautlos. Der Kanal verliert seinen Signalcharakter.
SMS – zuverlässig und durchdringend, aber eingeschränkt
SMS hat den Vorteil, dass sie auch bei schlechter Internetverbindung ankommen und auf den meisten Geräten ohne App-Installation funktionieren. Sie eignen sich gut als Backup für Telefonanrufe oder als primärer Kanal für mittelkritische Alerts (P2), bei denen eine Reaktion innerhalb von 15–30 Minuten erwartet wird. Der Nachteil: SMS transportiert kaum Kontext. Eine gute Alert-SMS enthält deshalb den Namen des Monitors, den Status und einen direkten Link zum Dashboard – nicht mehr.
Push-Benachrichtigung – für mobile On-Call-Personen
App-basierte Push-Benachrichtigungen über dedizierte On-Call-Apps (PagerDuty, OpsGenie oder integrierte Lösungen) sind heute der Standard für On-Call-Alarmierung außerhalb der Bürozeiten. Sie unterstützen Eskalationsstufen, Quittierungsworkflows und kritische Alarme mit höherer Lautstärke, die normale Do-Not-Disturb-Einstellungen durchdringen können. Für Teams mit einer definierten On-Call-Rotation sind dedizierte Push-Benachrichtigungen der bevorzugte Kanal für P1 und P2.
Slack und Microsoft Teams – für Information und Kollaboration
Chat-Plattformen sind exzellente Kanäle für Benachrichtigungen, die keine sofortige Reaktion erfordern: P3- und P4-Alerts, Statusänderungen, automatische Recovery-Meldungen. Sie haben den Vorteil, dass der Kontext direkt im Alert-Thread diskutiert werden kann – kein Wechsel zwischen Tools nötig. Außerdem können mehrere Teammitglieder passiv mitverfolgen, was gerade passiert, ohne aktiv involviert zu sein.
Der Nachteil von Slack als primärem Alert-Kanal für kritische Incidents: Nicht jeder hat Benachrichtigungen für alle Channels aktiviert, Mentions können übersehen werden, und auf mobilen Geräten bleibt Slack in vielen Do-Not-Disturb-Modi stumm. Für P1-Incidents ist Slack deshalb immer nur ein Ergänzungskanal, nie der einzige.
E-Mail – für Zusammenfassungen, nicht für Sofort-Alerts
E-Mail eignet sich gut für tägliche oder wöchentliche Monitoring-Zusammenfassungen, für Incident-Berichte nach einem Vorfall und für Eskalations-Dokumentation. Als primärer Alert-Kanal für operativen Betrieb ist sie zu langsam und zu leicht zu übersehen. Teams, die noch hauptsächlich per E-Mail alarmieren, sollten diesen Kanal gezielt durch schnellere Kanäle ergänzen.
Webhook – für Automatisierung und Tool-Integration
Webhooks sind kein Kanal für Menschen, sondern für Systeme. Sie ermöglichen es, Alert-Events direkt in andere Tools zu injizieren: Ticketing-Systeme, interne Plattformen, Automatisierungsworkflows. Ein eingehender Webhook kann automatisch ein Jira-Ticket erstellen, einen Runbook-Schritt auslösen oder ein KI-Modell mit der Fehleranalyse beauftragen.
Eskalationsketten richtig aufbauen
Eine gute Kanalstrategie denkt nicht nur darüber nach, welcher Kanal zu nutzen ist, sondern auch was passiert, wenn niemand reagiert. Eskalationsketten definieren, in welcher Reihenfolge und mit welchem Zeitabstand weitere Personen oder Kanäle aktiviert werden.
Ein typisches Eskalationsmodell für kritische Alerts:
- Minute 0: Push-Benachrichtigung an primäre On-Call-Person
- Minute 5 (keine Quittierung): Telefonanruf an dieselbe Person
- Minute 10 (noch keine Quittierung): Push an sekundäre On-Call-Person, zusätzlich Slack-Message an das Team-Channel
- Minute 15 (immer noch keine Reaktion): Anruf an Teamlead oder Manager
Wichtig: Eskalationsketten müssen regelmäßig gewartet werden. Falsche Kontaktdaten, abwesendes Personal ohne Vertretungsregelung oder veraltete Rotationspläne können dazu führen, dass selbst eine gut konzipierte Kette in der Praxis versagt.
Kanalstrategie nach Schweregrad
Eine einfache Faustregel: Je kritischer der Incident, desto höher die Durchdringungskraft des Kanals – und desto kleiner der Empfängerkreis der ersten Benachrichtigung.
Eine bewährte Zuordnung:
- P1 – kritisch: Anruf + Push, enges Eskalationsintervall (5–10 Minuten)
- P2 – erheblich: Push + SMS, Eskalationsintervall 15–20 Minuten
- P3 – beeinträchtigend: Slack/Chat, keine Eskalation, Review im nächsten Working Day
- P4 – informativ: E-Mail-Zusammenfassung oder internes Dashboard
FreshCore Notification Handler in der Praxis
FreshCore unterstützt mehrere Notification Handler, die sich pro Monitor, Heartbeat oder Gruppe individuell konfigurieren lassen. Teams können für unterschiedliche Ressourcen unterschiedliche Handler definieren: Ein produktionskritischer API-Monitor löst eine sofortige Push-Benachrichtigung aus, ein nicht-kritischer Monitoring-Check schreibt nur in einen Slack-Channel. Die granulare Kontrolle über Benachrichtigungen auf Ebene einzelner Ressourcen verhindert, dass ein einziger globaler Alert-Kanal zum Bottleneck oder zur Rauschquelle wird.
Alert-Fatigue aktiv bekämpfen
Alert-Fatigue entsteht, wenn On-Call-Personen so viele Alerts erhalten, dass sie beginnen, diese zu ignorieren oder reflexartig zu quittieren ohne tatsächliche Reaktion. Eine konsequente Kanalstrategie ist die wichtigste strukturelle Maßnahme dagegen – aber nicht die einzige.
Ergänzende Maßnahmen:
- Alert-Volumen regelmäßig reviewen: Wie viele Alerts pro Woche? Wie viele davon actionable?
- Flapping-Alerts separat behandeln: Monitore, die schnell zwischen OK und Fehler wechseln, sollten gedämpft werden
- Noise-Floor-Alerts eliminieren: Jeder Alert, der regelmäßig ohne Konsequenzen quittiert wird, ist ein Kandidat für Abschaltung oder Herabstufung
- Ruhige Fenster respektieren: Für unkritische Alerts Zeitfenster definieren, in denen keine Benachrichtigungen verschickt werden
Fazit
Eine durchdachte Kanalstrategie ist kein technisches Luxusprojekt – sie ist eine Grundvoraussetzung dafür, dass Monitoring tatsächlich wirkt. Wer die Kanäle nach Schweregrad strukturiert, Eskalationsketten regelmäßig pflegt und Alert-Fatigue aktiv misst, schafft die Voraussetzung für schnelle, zuverlässige Incident-Reaktionen – ohne das On-Call-Team auszubrennen.
Quellen:
Google Site Reliability Engineering Book – sre.google/sre-book
PagerDuty Incident Response – response.pagerduty.com
