Ein SRE-Team, das wir kennen, hatte in einer Woche 1.400 Alerts bekommen. Davon waren 23 handlungsrelevant. Die übrigen 1.377 waren Rauschen: bekannte fluktuierende Metriken, selbst-heilende Systeme, Alerts aus Umgebungen, die ohnehin niemand nutzte. Zwei erfahrene Engineers hatten das Team in den letzten sechs Monaten verlassen. Beide nannten On-Call als Hauptgrund.
Alert Fatigue – das Abstumpfen gegenüber Alarmen wegen schlechtem Signal-Rausch-Verhältnis – ist kein Randproblem. Es ist einer der häufigsten Gründe, warum Monitoring-Infrastruktur ihren eigentlichen Zweck verfehlt und warum Teams, die eigentlich Systeme absichern sollen, ihre Energie damit verbringen, Alerts zu stumm zu schalten.
Wie Alert Fatigue entsteht
Alerting-Systeme werden meistens nicht schlecht geplant. Sie werden gut geplant – und dann wächst das System.
Ein neuer Service kommt hinzu, der Entwickler kopiert die Alerting-Konfiguration des letzten Services. Ein Incident passiert, eine neue Metrik wird als kritisch erkannt und ein neuer Alert erstellt. Ein Audit empfiehlt mehr Monitoring-Coverage. Nach zwei Jahren hat das System dreimal so viele Alerts wie zu Beginn – aber die Trefferquote ist deutlich gesunken.
Das ist die typische Drift-Kurve: Alerts, die zu einem bestimmten Zeitpunkt sinnvoll waren, werden nicht deaktiviert, wenn die Bedingungen sich ändern. Staging-Umgebungen bekommen dieselbe Alerting-Konfiguration wie Produktion. Metriken, die selten stabile Werte haben, werden trotzdem mit engen Schwellwerten belegt. Das Ergebnis ist ein System, das viel signalisiert und wenig bedeutet.
Das eigentliche Problem: Alerts ohne Ownership
Eine Metrik, die niemand versteht oder niemand beheben kann, darf keinen Alert auslösen. Das klingt trivial und wird in der Praxis systematisch missachtet.
Wenn ein Alert auslöst und die On-Call-Person nicht weiß, was dieser Alert bedeutet, warum er gerade auslöst, und was die richtige Reaktion ist – dann ist der Alert keine Hilfe. Er ist eine Unterbrechung. Und Unterbrechungen um drei Uhr morgens, die zu keiner Handlung führen, akkumulieren zu Burnout.
Ownership von Alerts bedeutet: Für jeden Alert, der produktiv einen Menschen weckt, gibt es eine Person oder ein Team, das versteht, warum dieser Alert existiert, welches Runbook gilt und welche Konsequenz es hat, wenn nicht reagiert wird. Alerts ohne Ownership sind Rauschen, das als Signal verkleidet ist.
In vielen Teams gibt es keine systematische Überprüfung, wer für welchen Alert verantwortlich ist. Alerts werden erstellt, aber nie auditiert. Services sterben, Alerts bleiben. Das ändert sich nur durch einen bewussten Prozess – nicht durch ein besseres Alerting-Tool.
SLOs als Grundlage für sinnvolles Alerting
Der konzeptuell sauberste Ansatz für Alerting kommt aus dem SRE-Umfeld: Service Level Objectives (SLOs) als Basis für Alert-Entscheidungen.
Statt zu fragen “Welche Metrik soll einen Alert auslösen?”, fragt man: “Was muss gelten, damit dieser Service seinen Nutzern das zugesagte Erlebnis liefert?” Das Ergebnis ist eine SLO – etwa “99,5 % der Anfragen werden in unter 200 ms beantwortet, gemessen über ein 30-Tage-Fenster”.
Daraus folgt ein Error Budget: Wie viel “Schlechtigkeit” ist im Rahmen der SLO erlaubt? Wenn das Error Budget schnell verbrennt, gibt es einen Alert. Wenn es langsam verbrennt, gibt es ein Ticket. Wenn es nicht verbrennt, gibt es keinen Alert – auch wenn einzelne Metriken fluktuieren.
Dieses Modell hat einen entscheidenden Vorteil: Alerts sind direkt an das Nutzererlebnis gekoppelt. Ein Alert bedeutet: Die Nutzer spüren ein Problem, oder werden es bald spüren. Kein Alert bedeutet: Das System liefert das, was es versprochen hat – egal wie unruhig einzelne Metriken sind.
SLO-basiertes Alerting ist anspruchsvoll einzuführen, weil es voraussetzt, dass man überhaupt definiert hat, was ein “gutes” Nutzererlebnis für jeden Service bedeutet. Viele Teams haben diese Diskussion nie geführt. Das ist gleichzeitig eine Schwäche im Alerting-Setup und eine Schwäche im Produkt-Verständnis.
Was sich konkret ändern lässt
Ein Einstieg, der ohne große Neuarchitektur funktioniert:
Alert-Audit einmal pro Quartal. Welche Alerts haben im letzten Quartal ausgelöst? Welche davon haben zu einer tatsächlichen Handlung geführt? Alerts mit null handlungsrelevanten Auslösungen werden deaktiviert oder in eine “Low Priority”-Kategorie verschoben, die niemanden aus dem Schlaf holt.
Trennung von Pager-Alerts und Ticket-Alerts. Nicht jeder Alert, der Aufmerksamkeit verdient, verdient sofortige Aufmerksamkeit um drei Uhr morgens. Die Unterscheidung zwischen “jemanden wecken” und “in die Queue legen für morgen früh” ist eine der einfachsten Verbesserungen mit der größten Wirkung auf Lebensqualität im On-Call.
Post-Incident-Routine für Alert-Qualität. Nach jedem Incident: War der Alert hilfreich? Waren die Alert-Texte verständlich? Gab es Alerts, die nicht ausgelöst haben und hätten sollen? Diese Fragen sind Teil eines guten Postmortem – und werden selten gestellt.
On-Call ist unvermeidlich, wenn man Produktionssysteme betreibt. Alert Fatigue ist es nicht. Der Unterschied liegt nicht in der Anzahl der Monitoring-Tools, sondern in der Disziplin, mit der Teams definieren, was wirklich einen Menschen wecken soll – und was nicht.