Alert Fatigue reduzieren: Praxisleitfaden für SRE- und Rufbereitschaftsteams

Wer Alert Fatigue reduzieren möchte, sollte mit einer unbequemen Frage beginnen: Bei wie vielen Alarmen der letzten Woche musste tatsächlich ein Mensch etwas tun? In vielen Teams lautet die ehrliche Antwort „bei weniger als der Hälfte“. Der Rest waren Duplikate, flatternde Schwellwerte, Warnungen ohne Owner oder Folgesymptome eines Incidents, der ohnehin schon bearbeitet wurde. Jeder dieser Alarme bringt der Person in Bereitschaft bei, dass man Alerts ignorieren kann, und genau das führt dazu, dass irgendwann der eine wichtige Alarm untergeht.

Alarmmüdigkeit ist kein Problem mangelnder Belastbarkeit, sondern ein Designfehler im Alerting. Dieser Leitfaden zeigt die Maßnahmen in einer sinnvollen Reihenfolge: Symptome statt Ursachen alarmieren, auf SLO-Burn-Rate-Alerts umstellen, deduplizieren und gruppieren, nach Zuständigkeit und Schweregrad routen, jedem Page ein Runbook geben und den Alert-Bestand regelmäßig prüfen. Am Ende finden Sie eine kopierbare Checkliste für das Alert-Review, eine Entscheidungstabelle für typische Alert-Arten und zwei Kennzahlen, mit denen Sie den Erfolg messen.

Woher Alarmmüdigkeit kommt

Alert Fatigue entsteht schleichend. Jeder Alert wurde aus gutem Grund angelegt, meist nach einem Incident, und kaum einer wird je wieder entfernt. Typische Ursachen sind:

• Ursachenbasierte Schwellwerte: CPU über 80 Prozent, Festplatte über 70 Prozent, ein Pod neu gestartet. Solche Alerts feuern, wenn das System ausgelastet ist, nicht wenn Nutzer betroffen sind.
• Ein Alert pro Instanz: Ein Datenbank-Failover erzeugt vierzig Pages, einen pro abhängigem Service und Host, statt eines einzigen Incidents.
• Kein Owner: Alerts landen in einem gemeinsamen Kanal oder bei der Person, die gerade Dienst hat, auch wenn nur ein bestimmtes Team das Problem lösen kann.
• Keine definierte Handlung: Der Alert feuert, jemand schaut auf ein Dashboard, sieht, dass sich alles erholt hat, und schläft weiter. Gelernt wurde nichts, geändert wird nichts.
• Alles ist dringend: Warnungen und kritische Probleme nutzen denselben Kanal, denselben Ton und dieselbe Eskalation. Der Schweregrad transportiert damit keine Information mehr.

Das Ergebnis ist ein Team, das Alarme reflexhaft quittiert, spät reagiert und ausbrennt. Rufbereitschaft darf bei echten Incidents fordernd sein, sollte aber die übrige Zeit ruhig bleiben. Ist sie jede Nacht laut, ist der Alert-Bestand das Problem, nicht die Menschen.

Symptombasiertes statt ursachenbasiertes Alerting

Die wirksamste einzelne Änderung lautet: bei Symptomen alarmieren, Ursachen untersuchen. Ein Symptom ist etwas, das Nutzer oder nachgelagerte Systeme bemerken: Anfragen schlagen fehl, der Checkout ist langsam, Nachrichten kommen verspätet an. Eine Ursache ist etwas, das zu einem Symptom führen kann: hohe CPU-Last, eine volle Queue, ein neu gestarteter Container.

Ursachenbasierter Alert (untersuchen)	Symptombasierter Alert (alarmieren)
CPU auf api-7 seit 5 Minuten über 85 Prozent	Fehlerrate der Checkout-API verbraucht das SLO-Budget
Kafka-Consumer-Lag über 10.000 Nachrichten	Bestellungen werden später als 2 Minuten nach Zahlung bestätigt
Pod dreimal neu gestartet	p95-Latenz des Login-Endpunkts über 800 ms
Datenbankverbindungen über 90 Prozent des Pools	Synthetischer Check der wichtigsten Nutzerreise schlägt aus zwei Regionen fehl

Die Schwellwerte in der Tabelle sind Beispiele, keine Empfehlungen. Ursachenbasierte Signale bleiben wertvoll: Sie gehören auf Dashboards, in Tickets oder als Kontext an den Symptom-Alert, damit die zuständige Person an einer Stelle sieht: „Fehlerrate hoch, und der Connection-Pool der primären Datenbank ist ausgeschöpft.“ Wecken sollten sie allein nur selten. Ausnahmen sind Ursachen, die ein Symptom sicher vorhersagen und wenig Reaktionszeit lassen, etwa eine Festplatte, die in der nächsten Stunde voll ist, oder ein Zertifikat, das morgen abläuft.

SLO- und Burn-Rate-Alerts

Präzise wird symptombasiertes Alerting über Service Level Objectives. Sie wählen einen Service Level Indicator wie den Anteil erfolgreicher Anfragen, legen ein Ziel fest, etwa 99,9 Prozent über 30 Tage, und leiten daraus ein Error Budget ab: 0,1 Prozent der Anfragen dürfen fehlschlagen. Die Grundlagen erklärt unser Beitrag Was ist ein SLO?.

Statt direkt auf die Fehlerrate zu alarmieren, alarmieren Sie auf die Burn Rate, also die Geschwindigkeit, mit der das Budget verbraucht wird. Eine Burn Rate von 1 verbraucht das Budget genau über das SLO-Fenster, eine Burn Rate von 10 hätte ein 30-Tage-Budget nach drei Tagen aufgebraucht. Das Google SRE Workbook (Kapitel „Alerting on SLOs“) beschreibt einen Ansatz mit mehreren Fenstern und Burn Rates, den viele Teams als Ausgangspunkt nutzen:

• Page: Burn Rate über 14,4 in der letzten Stunde, bestätigt durch die letzten 5 Minuten. Das entspricht etwa 2 Prozent eines 30-Tage-Budgets in einer Stunde.
• Page: Burn Rate über 6 in den letzten 6 Stunden, bestätigt durch die letzten 30 Minuten, also etwa 5 Prozent des Budgets.
• Ticket: Burn Rate über 1 in den letzten 3 Tagen, bestätigt durch die letzten 6 Stunden, also etwa 10 Prozent des Budgets.

Das kurze Bestätigungsfenster sorgt dafür, dass der Alert nach der Behebung schnell zurückgesetzt wird, das lange Fenster filtert kurze Spitzen heraus. Ein SLO mit zwei oder drei Burn-Rate-Regeln ersetzt oft Dutzende Schwellwert-Alerts auf Fehlerrate und Latenz. Wie Sie dieselben Zahlen für Release-Gates und Budget-Richtlinien nutzen, zeigt unser Artikel SLOs in der Praxis.

Deduplizierung, Gruppierung und Unterdrückung

Auch gute Alerts werden zu Rauschen, wenn ein einzelner Fehler sie vielfach auslöst. Drei Mechanismen sorgen dafür, dass ein Problem genau eine Benachrichtigung erzeugt:

• Deduplizierung: Wiederholtes Feuern desselben Alerts mit denselben Labels aktualisiert einen offenen Alert, statt eine neue Benachrichtigung zu senden. Definieren Sie einen stabilen Fingerprint, zum Beispiel Alert-Name plus Service plus Umgebung, und lassen Sie flüchtige Labels wie den Pod-Namen weg.
• Gruppierung: Zusammenhängende Alerts, die in einem kurzen Zeitfenster feuern, werden zu einem Incident gebündelt, etwa alle Alerts des Payment-Service in Produktion innerhalb von fünf Minuten. Gruppieren Sie zunächst nach Service und Umgebung; noch besser funktioniert die Gruppierung über die Topologie, wenn Ihre Plattform die Abhängigkeiten zwischen Services kennt.
• Unterdrückung (Inhibition): Ist ein übergeordneter Alert aktiv, werden abhängige Alerts zurückgehalten. Wenn die primäre Datenbank ausfällt, braucht niemand vierzig einzelne Pages für die Services, die sie nicht erreichen. Unterdrücken Sie Alerts außerdem in geplanten Wartungsfenstern und bei Deployments, die bekanntermaßen kurze Ausschläge verursachen.

Ergänzen Sie verbleibende Schwellwert-Alerts um eine Hysterese: Die Bedingung muss einige Minuten anliegen, bevor der Alert feuert, und einige Minuten wieder unauffällig sein, bevor er zurückgesetzt wird. Damit verschwinden die meisten flatternden Alerts, die um einen Schwellwert herum ständig an- und ausgehen.

Routing, Schweregrad und Eskalation

Ein Page sollte die Person erreichen, die das Problem lösen kann, und zwar über einen Kanal, der zur Dringlichkeit passt. Drei Regeln decken die meisten Setups ab:

1. Nach Zuständigkeit routen: Jeder Alert trägt ein Service- oder Team-Label, und das Routing nutzt dieses Label. Alerts ohne Owner gelangen nicht in den Alarmierungspfad.
2. Schweregrade über Kanäle trennen: Nutzen Sie klar definierte Incident-Schweregrade. Nur die obersten Stufen alarmieren per Anruf oder Push-Benachrichtigung; niedrigere Stufen erzeugen ein Ticket oder eine Nachricht im Teamkanal während der Arbeitszeit.
3. Bei Stille eskalieren, nicht bei Lärm: Quittiert die primäre Bereitschaft nicht innerhalb einer festgelegten Zeit, geht der Alarm an die sekundäre Bereitschaft und dann an die Teamleitung. Eskalieren Sie nicht, nur weil ein bereits quittierter Alert weiter feuert.

Halten Sie die Routing-Regeln an einer Stelle fest, idealerweise als Code im selben Repository wie die Alert-Definitionen. Auf die Frage „Warum wurde ich dafür geweckt?“ sollte die Antwort nur eine Datei entfernt sein.

Ein Runbook für jeden Page

Ein Alert ohne bekannten nächsten Schritt zwingt die zuständige Person, im ungünstigsten Moment bei null anzufangen. Jeder alarmierende Alert sollte auf ein Runbook mit kurzer, fester Struktur verlinken. Eine bewährte Vorlage:

Alert:          checkout-availability-burn-rate-fast
Owner:          team-payments
Schweregrad:    SEV2 (alarmiert primäre Bereitschaft)
Bedeutung:      Checkout-Anfragen schlagen so häufig fehl, dass
                pro Stunde etwa 2 % des Monatsbudgets verbraucht werden.
Auswirkung:     Ein Teil der Kunden kann keine Bestellung abschließen.
Erste Prüfung:  1. Letzte Deployments von checkout oder payment-gateway
                2. Fehler nach Endpunkt und Statuscode
                3. Zustand des Zahlungsanbieters (Statusseite, Latenz)
Gegenmaßnahme:  Letztes Deployment zurückrollen | Anbieter wechseln |
                Wartungshinweis aktivieren
Eskalation:     team-platform, falls Datenbank oder Netzwerk betroffen
Zuletzt geprüft: 2026-10-01

Wenn Sie „Bedeutung“ und „Erste Prüfung“ nicht ausfüllen können, ist das ein deutliches Zeichen, dass der Alert nicht alarmieren sollte. Runbooks machen außerdem Automatisierung möglich: Schritte, die immer gleich ablaufen, etwa Diagnosedaten sammeln oder das letzte Deployment zurückrollen, können automatisch ausgeführt und dem Alert angehängt werden, bevor ein Mensch überhaupt hinschaut.

Alert-Hygiene: die Checkliste für das Alert-Review

Ein einmaliges Aufräumen hilft für ein paar Monate. Dauerhaft wirkt nur ein regelmäßiges Review, zum Beispiel 30 Minuten pro Monat oder nach jeder Bereitschaftsrotation, in dem das Team jeden Alert durchgeht, der im Zeitraum gefeuert hat. Kopieren Sie diese Checkliste in Ihr Review-Dokument:

ALERT-REVIEW-CHECKLISTE (pro Alert, der im Zeitraum gefeuert hat)

[ ] Haben Nutzer oder nachgelagerte Systeme ein Problem bemerkt?
[ ] Musste die Bereitschaft handeln? Wenn ja, wie?
[ ] Hätte sich diese Handlung automatisieren lassen?
[ ] War der Alert ein Duplikat eines anderen Alerts oder Incidents?
[ ] Hat er außerhalb der Arbeitszeit gefeuert? War das gerechtfertigt?
[ ] Passt der Schweregrad zur tatsächlichen Auswirkung?
[ ] Hat er beim ersten Versuch das richtige Team erreicht?
[ ] Hat er ein Owner-Label und einen funktionierenden Runbook-Link?
[ ] Hat er geflattert (mehr als zweimal pro Stunde an und aus)?
[ ] Würde ein SLO-Burn-Rate-Alert denselben Fall abdecken?
[ ] Entscheidung: behalten | anpassen | in Ticket umwandeln | löschen
[ ] Verantwortliche Person und Termin für die Nacharbeit notiert

Mit dieser Entscheidungstabelle werden aus den Antworten einheitliche Ergebnisse:

Alert-Art	Entscheidung	Begründung
SLO-Burn-Rate-Alert, schnelles Fenster	Behalten (Page)	Direkte Nutzerauswirkung und dringender Budgetverbrauch
SLO-Burn-Rate-Alert, langsames Fenster	In Ticket umwandeln	Echtes Problem, kann aber bis zur Arbeitszeit warten
Synthetischer Check einer kritischen Nutzerreise schlägt an mehreren Standorten fehl	Behalten (Page)	Starkes Symptomsignal mit wenigen Fehlalarmen
Festplatte oder Zertifikat läuft voraussichtlich in wenigen Stunden aus	Behalten (Page)	Sichere Auswirkung, wenig Reaktionszeit
Festplatte oder Zertifikat läuft voraussichtlich in einigen Tagen aus	In Ticket umwandeln	Auswirkung sicher, aber nicht dringend
Hohe CPU- oder Speicherlast auf einem einzelnen Host	Löschen oder aufs Dashboard verschieben	Ursache, kein Symptom; durch Latenz- und Fehler-SLOs abgedeckt
Einzelner Pod-Neustart	Löschen	In Kubernetes normal; stattdessen auf Crash-Loops oder SLO-Auswirkung alarmieren
Anomalie in einer Geschäftskennzahl (Bestellungen, Registrierungen)	Ticket oder Benachrichtigung mit niedrigem Schweregrad	Wertvoller Kontext, muss vor einer Alarmierung aber oft bestätigt werden
Alert ohne Owner und ohne Runbook	Nach 30 Tagen löschen, falls niemand ihn übernimmt	Niemand kann darauf reagieren
Alert, der seit 12 Monaten nicht gefeuert hat	Prüfen und testen	Kann defekt, veraltet oder weiterhin wichtig sein

Alert-Qualität messen

Ohne Zahlen wird Alert-Hygiene schnell zur Gefühlsdebatte. Zwei Kennzahlen lassen sich leicht aus Ihrem Alarmierungstool gewinnen und gut im Review besprechen:

• Anteil handlungsrelevanter Alerts: Pages, die eine menschliche Handlung erforderten, geteilt durch alle Pages im Zeitraum. Markieren Sie jeden Page während der Schicht oder im Review als handlungsrelevant oder nicht. Verfolgen Sie den Trend pro Team, statt einem universellen Zielwert hinterherzulaufen.
• Pages pro Bereitschaftsschicht: die Zahl der Alarme pro Schicht, getrennt nach Arbeitszeit und Nacht. Das Google SRE Book (Kapitel „Being On-Call“) betont, dass pro Incident genug Zeit für Bearbeitung und Nacharbeit bleiben muss, und nennt als Richtwert höchstens zwei Incidents pro 12-Stunden-Schicht. Nutzen Sie das als Orientierung, nicht als starre Regel.

Hilfreiche ergänzende Kennzahlen sind der Anteil der Alerts, die sich ohne Quittierung selbst auflösen, die Zahl der Alerts pro Incident (ein hoher Wert deutet auf schwache Gruppierung hin), die Zeit bis zur Quittierung nachts im Vergleich zum Tag sowie die Zahl der Alerts ohne Owner oder Runbook. Ein rein illustratives Beispiel: Ein Team mit 25 Pages pro Woche, von denen 8 eine Handlung erforderten, kommt auf einen Anteil von 32 Prozent und hat eine klare Liste von 17 Alerts, die zuerst ins Review gehören.

Auch die Erkennungsgeschwindigkeit zählt. Wenn Sie Rauschen entfernen, Incidents aber plötzlich von Kunden gemeldet werden, sind Sie zu weit gegangen. Beobachten Sie die Zeit bis zur Erkennung parallel zu den Rauschkennzahlen und prüfen Sie, ob jeder vergangene Incident auch mit dem neuen Alert-Bestand erkannt worden wäre.

Wie Obseria unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform, deren Alerting auf den Prinzipien dieses Leitfadens aufbaut: SLOs mit Burn-Rate-Alerts über mehrere Zeitfenster, Incidents, die zusammengehörige Signale bündeln, und eine Topologie, die die Abhängigkeiten zwischen Services kennt. Obseria Intelligence verknüpft Alerts mit Deployments, Traces und Anomalien und zeigt die Belege hinter einer vorgeschlagenen Ursache, sodass die Bereitschaft mit Kontext statt mit einem nackten Schwellwert startet.

• SLOs mit Burn-Rate-Alerting und Error-Budget-Verfolgung pro Service
• Incident-Management mit Gruppierung, Routing nach Zuständigkeit, Eskalation und Statusseiten
• Anomalie-Erkennung als Kontext für Alerts oder Benachrichtigungen mit niedrigem Schweregrad statt zusätzlicher Pages
• Automatisierung, die Runbook-Schritte wie Diagnose oder Rollback ausführt und die Ergebnisse dem Incident anhängt

Wie Ihre bestehenden Alerts als SLOs und gruppierte Incidents aussehen würden, sehen Sie am besten mit Ihren eigenen Daten: Jetzt kostenlos testen.