Alerting bedeutet: Ein System schlägt automatisch Alarm, sobald eine Kennzahl aus dem Ruder läuft. Statt dass jemand stündlich auf ein Dashboard starrt, definierst Du vorab Schwellen und Regeln — und das Monitoring meldet sich von selbst, wenn etwas davon abweicht. Per E-Mail, Slack, SMS, Push oder einem Anruf mitten in der Nacht, je nachdem, wie kritisch es ist.
Der Kern ist eine Umkehrung der Arbeitsweise: Nicht der Mensch sucht den Fehler, der Fehler findet den Menschen. Für einen Online-Shop ist das überlebenswichtig. Ein Checkout, der seit zwei Stunden Fehler wirft, kostet bares Geld — und in zwei Stunden kannst Du je nach Traffic einen vierstelligen Umsatz verlieren, ohne es zu merken. Alerting verkürzt die Zeit zwischen „etwas ist kaputt" und „jemand weiß davon" von Stunden auf Sekunden.
Monitoring, Alerting, Observability — wo liegt der Unterschied?
Die drei Begriffe werden gern in einen Topf geworfen, meinen aber Verschiedenes. Monitoring ist das kontinuierliche Sammeln und Anzeigen von Messwerten — Server-Last, Antwortzeiten, Fehlerraten. Es zeigt Dir den Zustand. Alerting ist die Schicht obendrauf, die aus diesen Messwerten eine Aktion ableitet: Wenn Wert X die Schwelle Y überschreitet, benachrichtige Z. Observability geht weiter und fragt, ob Du aus den gesammelten Daten überhaupt herleiten kannst, warum etwas passiert ist.
Kurz: Monitoring sieht, Alerting ruft, Observability erklärt. Ohne Alerting ist Monitoring ein Dashboard, das niemand anschaut, wenn es darauf ankommt.
Wovon ein Alert ausgelöst wird
Alerts entstehen aus Bedingungen über Metriken oder Logs. Die typischen Auslöser im E-Commerce-Umfeld:
- Schwellenwert-Alerts: Eine Metrik über- oder unterschreitet einen festen Wert. Beispiel: CPU-Auslastung über 90 Prozent, oder Conversion Rate unter die Hälfte des Tagesschnitts.
- Fehlerraten-Alerts: Der Anteil fehlerhafter Anfragen (HTTP 5xx) steigt über eine definierte Grenze.
- Verfügbarkeits-Alerts: Ein Healthcheck oder eine Synthetic-Probe erreicht den Shop nicht mehr — der Klassiker für „Seite ist down".
- Anomalie-Alerts: Statt fester Schwellen erkennt das System eine Abweichung vom gelernten Normalverhalten. Hilfreich bei Metriken mit starkem Tagesrhythmus, wo ein fester Wert nicht passt.
- Heartbeat-/Dead-Man-Switch-Alerts: Es schlägt Alarm, wenn ein erwartetes Signal ausbleibt — etwa ein nächtlicher Cronjob, der nicht mehr meldet, dass er gelaufen ist.
Wie ein gutes Alert aufgebaut ist
Ein Alert ist mehr als ein „irgendwas ist rot". Brauchbar wird er erst durch Kontext. Ein gut gebautes Alert beantwortet drei Fragen sofort: Was ist passiert, wie schlimm ist es, und was soll der Empfänger jetzt tun? Eine Benachrichtigung mit dem Text „DiskUsageWarning on prod-db-01" ohne Schweregrad und ohne Handlungshinweis erzeugt nur Stress, keine Reaktion.
Deshalb haben sich Schweregrade etabliert. Eine pragmatische Staffelung:
| Severity | Bedeutung | Reaktion | Kanal |
|---|---|---|---|
| Critical (P1) | Shop down, Checkout kaputt, Datenverlust droht | sofort, auch nachts | Anruf / PagerDuty |
| High (P2) | Teilausfall, Performance stark degradiert | innerhalb der Arbeitszeit, zeitnah | SMS / Slack-Mention |
| Warning (P3) | Trend läuft in die falsche Richtung | im Tagesgeschäft prüfen | Slack-Channel |
| Info (P4) | reines Logging, kein Handlungsbedarf | keine | Dashboard / Ticket |
Die häufigste Sünde: Alles als Critical zu deklarieren. Dann klingelt nachts das Telefon, weil ein Logfile-Verzeichnis zu 80 Prozent voll ist. Das Ergebnis ist Alert-Fatigue — und die ist gefährlicher als gar kein Alerting.
Alert-Fatigue: Wenn zu viele Alarme zum eigentlichen Risiko werden
Wenn ein Team täglich Dutzende Alerts bekommt, von denen die meisten harmlos sind oder von selbst verschwinden, stumpft es ab. Irgendwann werden Benachrichtigungen reflexhaft weggeklickt — und dann geht der eine Alert unter, der wirklich zählte. Dieses Phänomen ist in der Praxis der Hauptgrund, warum Alerting scheitert, nicht fehlende Technik.
Gegenmittel: Schwellen ehrlich kalibrieren, statt sie aus Angst niedrig zu setzen. Verwandte Alerts gruppieren, damit ein Ausfall nicht fünfzig Einzelmeldungen erzeugt. Und konsequent ausmisten — jedes Alert, das in den letzten Monaten nie zu einer Handlung führte, gehört auf den Prüfstand. Google formuliert in seinem viel zitierten Site-Reliability-Engineering-Buch die Leitlinie, dass jedes Alert, das einen Menschen weckt, actionable sein muss. Nachzulesen frei zugänglich: Google SRE Book — Monitoring Distributed Systems.
Ein konkretes Praxisbeispiel
Ein Shopware-Shop verkauft pro Tag im Schnitt rund 500 Bestellungen, mit klarem Tagesverlauf: vormittags wenig, abends Peak. Der Betreiber richtet folgende Alerting-Regel ein: „Wenn die Zahl der erfolgreich abgeschlossenen Bestellungen über einen Zeitraum von 30 Minuten um mehr als 70 Prozent unter dem erwarteten Wert für diese Tageszeit liegt, löse einen High-Alert in den Operations-Slack-Channel aus."
An einem Dienstagabend um 20:15 Uhr — eigentlich Stoßzeit — fällt die Bestellrate plötzlich auf nahezu null. Das Anomalie-Alert feuert nach acht Minuten. Im Channel landet die Meldung mit Kontext: erwartete Bestellungen 45, tatsächliche 3, Link zum Dashboard, letzter Deploy vor 22 Minuten. Das Team schaut sofort nach und findet die Ursache: Ein Deployment hat eine Zahlungsart-Konfiguration zerschossen, der Checkout bricht beim Bezahlschritt ab.
Ohne Alerting hätte das vielleicht erst am nächsten Morgen jemand bemerkt — über die Hälfte des Abendumsatzes wäre weg gewesen. Mit Alerting war der Fehler nach 25 Minuten behoben. Die Rechnung ist simpel: Die paar Stunden Aufwand fürs Einrichten der Regel haben sich an genau diesem einen Abend bezahlt gemacht.
Alerting sauber aufsetzen — die Grundregeln
Es gibt keinen Goldstandard, der für jeden Shop passt, aber es gibt Prinzipien, die sich bewährt haben:
- Auf Symptome alarmieren, nicht auf Ursachen. „Kunden können nicht bezahlen" ist ein nützliches Alert. „CPU bei 85 Prozent" ist es oft nicht — solange der Shop normal läuft, ist eine hohe CPU-Last erstmal nur eine Zahl.
- Jedes Alert braucht einen Adressaten und eine Handlung. Wenn niemand zuständig ist oder niemand etwas tun kann, ist es kein Alert, sondern Rauschen.
- Eskalationsketten definieren. Reagiert der erste Empfänger nicht in X Minuten, geht der Alarm an den nächsten. So fällt nichts durch, weil jemand im Kino sitzt.
- Alerts versionieren und reviewen. Behandle Alert-Regeln wie Code. Nach jedem Vorfall fragst Du: Hätte ein Alert das früher gefangen? Hat ein Alert unnötig gefeuert?
Werkzeuge im Überblick
Die Toollandschaft ist breit. Prometheus mit Alertmanager ist im Open-Source-Lager der De-facto-Standard für metrikbasiertes Alerting. Grafana liefert die Visualisierung dazu und kann selbst alarmieren. Für die Benachrichtigungs- und Eskalationsseite haben sich PagerDuty oder Opsgenie etabliert. Im Cloud-Umfeld bringen AWS CloudWatch, Google Cloud Monitoring und Azure Monitor eigene Alerting-Engines mit. Für reine Verfügbarkeitsprüfungen reichen oft schlanke Uptime-Dienste, die Deinen Shop von außen anpingen.
Welches Werkzeug, ist zweitrangig. Entscheidend ist, dass jemand die Regeln pflegt und dass die Alerts tatsächlich bei einem wachen Menschen ankommen.
Schwellenwerte vernünftig setzen
Die schwierigste Frage im Alerting ist nicht das „Ob", sondern das „Ab wann". Setzt Du die Schwelle zu niedrig, feuert das Alert ständig und wird zu Rauschen. Setzt Du sie zu hoch, merkst Du das Problem erst, wenn es schon weh tut. Es gibt keinen universell richtigen Wert — er ergibt sich aus dem Normalverhalten Deines Systems und aus der Frage, ab wann ein Mensch wirklich eingreifen muss.
Ein bewährtes Vorgehen: Beobachte zuerst über mehrere Wochen, ohne zu alarmieren. Lerne, wie sich eine Metrik im Normalbetrieb verhält — mit ihren Tages-, Wochen- und Saison-Schwankungen. Erst dann legst Du eine Schwelle fest, die das normale Auf und Ab nicht trifft, aber echte Ausreißer fängt. Statische Schwellen funktionieren gut bei Metriken mit klarer Obergrenze (Speicherplatz, Fehlerrate). Bei Metriken mit starkem Rhythmus, etwa der Bestellrate, fahren dynamische oder anomaliebasierte Schwellen besser.
Ein zweiter Hebel gegen Fehlalarme ist die Dauer. Statt sofort beim ersten Überschreiten zu alarmieren, wartest Du, ob der Zustand über einen Zeitraum anhält. Eine einzelne Spitze von zwei Sekunden ist meist harmlos; eine erhöhte Fehlerrate, die fünf Minuten anhält, ist es nicht. Diese „for"-Bedingung filtert einen Großteil der nervösen Fehlalarme heraus.
Geschäftsmetriken alarmieren, nicht nur Technik
Die meisten Alerting-Setups konzentrieren sich auf Infrastruktur: Server, Datenbanken, Speicherplatz, Netzwerk. Das ist nötig, aber nicht ausreichend. Denn ein Shop kann technisch tadellos laufen — alle Server grün, alle Datenbanken antworten — und trotzdem kein Geld verdienen, weil ein Bug im Bestellprozess steckt, den keine Server-Metrik anzeigt.
Deshalb gehören Geschäftsmetriken ins Alerting. Die wirkungsvollsten Signale für einen Online-Shop sind oft die naheliegendsten:
- Bestellungen pro Zeitraum: Ein plötzlicher Einbruch ist das zuverlässigste Frühwarnsignal für einen kaputten Checkout.
- Conversion Rate: Sackt sie ohne Traffic-Einbruch ab, stimmt etwas im Funnel nicht.
- Zahlungsfehlerquote: Steigt der Anteil fehlgeschlagener Zahlungen, hängt oft ein Payment-Provider oder eine fehlerhafte Konfiguration dahinter.
- Warenkorbabbrüche im letzten Schritt: Ein sprunghafter Anstieg deutet auf einen Fehler genau dort, wo es am teuersten ist.
Der Charme dieser Metriken: Sie messen die Wirkung, nicht die Ursache. Du musst nicht wissen, welches der hundert technischen Dinge kaputtgehen kann — Du merkst es daran, dass die Kunden nicht mehr kaufen. Das ist robustes Alerting, weil es auch Fehler fängt, an die niemand gedacht hat.
Runbooks: Was tun, wenn das Alert feuert?
Ein Alert ohne Plan ist halbe Arbeit. Reife Teams hängen an jedes wichtige Alert ein Runbook — eine knappe Anleitung, was beim Feuern zu prüfen ist und welche ersten Schritte helfen. Im Idealfall verlinkt das Alert dieses Runbook direkt. Dann muss der Mensch, der um drei Uhr nachts geweckt wird, nicht erst überlegen, wo er anfängt: erst dieses Dashboard prüfen, dann jenen Service neu starten, im Zweifel diese Person eskalieren.
Runbooks haben einen angenehmen Nebeneffekt: Sie machen Wissen unabhängig von einzelnen Köpfen. Fällt der eine Kollege aus, der „immer weiß, woran es liegt", steht das Team sonst im Dunkeln. Ein gepflegtes Runbook verteilt dieses Wissen.
Typische Fehler
Drei Muster sehen wir immer wieder. Erstens: Alerting wird eingerichtet und dann nie wieder angefasst — bis die halbe Belegschaft die Benachrichtigungen stummgeschaltet hat. Zweitens: Es wird nur auf technische Metriken alarmiert (Server, Datenbank), nie auf Geschäftsmetriken (Bestellungen, Umsatz). Dabei merkst Du einen kaputten Bezahlbutton viel zuverlässiger am Bestelleinbruch als an der CPU-Last. Drittens: Keine Stille-Phasen (Maintenance Windows) für geplante Arbeiten, sodass jedes Deployment einen Alert-Sturm auslöst und das Team konditioniert wird, Alarme zu ignorieren.
Gutes Alerting ist kein Produkt, das man kauft und abhakt. Es ist eine Disziplin: wenige, scharfe, handlungsleitende Signale statt vieler nervöser. Wenn ein Alert feuert, sollte die normale Reaktion sein „oh, das muss ich anschauen" — nicht „schon wieder das Ding, ignorier ich".