Alerting

Alerting bedeutet: Ein System schlägt automatisch Alarm, sobald ein vorab definierter Zustand eintritt — eine Kennzahl überschreitet eine Schwelle, ein erwartetes Signal bleibt aus oder ein Fehler häuft sich. Statt dass jemand stündlich auf ein Dashboard starrt, legst Du vorab Regeln fest, und das System meldet sich von selbst, wenn etwas davon abweicht. Per E-Mail, Slack, SMS, Push-Nachricht oder einem Anruf mitten in der Nacht, je nachdem, wie kritisch der Vorfall 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 je nach Traffic verlierst Du in dieser Zeit einen vierstelligen Umsatz, ohne es zu merken. Alerting verkürzt die Spanne zwischen „etwas ist kaputt" und „jemand weiß davon" von Stunden auf Sekunden. Eine kompakte Einordnung des Konzepts liefert auch der Wikipedia-Artikel zu Network Monitoring, in dessen Umfeld Alerting historisch entstanden ist.

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 gesagt: Monitoring sieht, Alerting ruft, Observability erklärt. Ohne Alerting ist Monitoring nur ein Dashboard, das niemand anschaut, wenn es darauf ankommt. Alerting ist also nicht die teuerste, aber oft die folgenreichste der drei Schichten — denn sie entscheidet, ob aus einer Messung überhaupt eine Reaktion wird.

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- bzw. 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 (Severity-Stufen) etabliert. Eine pragmatische Staffelung:

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 Alarm unter, der wirklich zählte. Dieses Phänomen ist in der Praxis der Hauptgrund, warum Alerting scheitert, nicht fehlende Technik.

Gegen Alert-Fatigue helfen ein paar Hebel, die zusammenwirken:

• Deduplizierung: Tausend identische Fehler erzeugen ein Alert, nicht tausend. Gleichartige Signale werden zusammengefasst.
• Bündelung (Grouping): Verwandte Alerts eines Vorfalls landen in einer Benachrichtigung, statt fünfzig Einzelmeldungen auszulösen.
• Eskalation: Reagiert niemand, wandert der Alarm nach X Minuten an die nächste Person — statt ihn lauter zu wiederholen.
• Ehrliche Schwellen: Grenzwerte werden am Normalverhalten kalibriert, nicht aus Angst niedrig gesetzt.
• Regelmäßiges 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 — andernfalls gehört es abgeschafft. Frei zugänglich nachzulesen im 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.

Werkzeuge im Überblick — von Prometheus bis n8n

Die Toollandschaft ist breit, und unterschiedliche Werkzeuge decken unterschiedliche Ebenen ab:

• Prometheus mit Alertmanager: im Open-Source-Lager der De-facto-Standard für metrikbasiertes Alerting. Prometheus sammelt Zeitreihen, definiert Alert-Regeln, und der Alertmanager übernimmt Deduplizierung, Gruppierung, Stummschaltung (Silencing) und das Routing an die richtigen Kanäle.
• Grafana: liefert die Visualisierung und kann selbst alarmieren, gespeist aus denselben Datenquellen.
• PagerDuty und Opsgenie: spezialisiert auf die Benachrichtigungs- und Eskalationsseite — On-Call-Pläne, Telefonketten, Eskalation über mehrere Stufen.
• Cloud-native Engines: AWS CloudWatch, Google Cloud Monitoring und Azure Monitor bringen eigenes Alerting mit, wenn der Stack ohnehin dort liegt.
• No-Code-Workflows mit n8n: für geschäftsnahes Alerting, das näher am Tagesgeschäft als an der Infrastruktur sitzt. Ein n8n-Error-Workflow fängt zum Beispiel jeden fehlgeschlagenen Lauf eines Automations-Workflows ab und schickt eine formatierte Slack-Nachricht ins Team. Genauso lässt sich eine Bestell- oder Lagerbestand-Schwelle ohne eine Zeile Code überwachen.

Gerade der letzte Punkt ist für den Mittelstand interessant: Nicht jedes sinnvolle Alert braucht eine Observability-Plattform. Eine schlanke Automatisierung, die ein Geschäftssignal beobachtet und im Ernstfall das richtige Team benachrichtigt, lässt sich mit Werkzeugen wie n8n in Stunden statt Wochen aufsetzen. Wir zeigen ein solches Setup Schritt für Schritt in unserem Beitrag Alarmierung mit n8n, und wie sich No-Code-Alerting in größere Abläufe einbettet, gehört zur Prozessautomatisierung & KI-Workflows.

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. So sieht eine typische Prometheus-Alert-Regel aus, die genau das tut:

groups:
  - name: shop-alerts
    rules:
      - alert: HoheFehlerrate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Über 5 % 5xx-Fehler seit 5 Minuten"
          runbook: "https://wiki.example.de/runbooks/5xx"

Die for: 5m-Bedingung sorgt dafür, dass eine einzelne Spitze von zwei Sekunden keinen Alarm auslöst — erst ein Zustand, der fünf Minuten anhält, ist ernst. Diese 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 und Eskalation: Was nach dem Alarm passiert

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.

Dazu gehört eine saubere Eskalationskette: Reagiert der erste On-Call-Empfänger nicht in der vereinbarten Zeit, übernimmt automatisch der nächste. Werkzeuge wie PagerDuty oder Opsgenie bilden genau diese Ketten ab — inklusive Bereitschaftsplänen, damit nicht dauerhaft dieselbe Person nachts wach liegt. So fällt kein kritischer Alarm durch, nur weil jemand gerade im Kino sitzt.

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".

Häufige Fragen

Was ist der Unterschied zwischen Alerting und Monitoring?
Monitoring sammelt und zeigt Messwerte an — es ist der Dauerblick auf den Systemzustand. Alerting ist die Schicht darüber, die aus diesen Werten eine aktive Benachrichtigung ableitet, sobald eine definierte Bedingung erfüllt ist. Ohne Alerting bleibt Monitoring ein Dashboard, das nur wirkt, solange jemand hinschaut.

Was ist Alert-Fatigue und wie vermeide ich sie?
Alert-Fatigue ist die Abstumpfung eines Teams durch zu viele, meist harmlose Alarme. Die Folge: Auch wichtige Alerts werden reflexhaft ignoriert. Gegenmittel sind ehrlich kalibrierte Schwellen, Deduplizierung, Bündelung verwandter Alerts, Eskalationsketten und regelmäßiges Ausmisten von Regeln, die nie zu einer Handlung führen.

Welche Kanäle eignen sich für Alerts?
Das hängt vom Schweregrad ab. Unkritisches gehört in einen Slack- oder Teams-Channel, den man im Tagesgeschäft prüft. Wirklich kritische Vorfälle — Shop down, Checkout kaputt — brauchen einen Kanal, der auch nachts durchdringt: SMS, Push oder Anruf über einen On-Call-Dienst wie PagerDuty.

Brauche ich für Alerting teure Spezial-Tools?
Nicht zwingend. Für metrikbasiertes Infrastruktur-Alerting ist Prometheus mit Alertmanager Open Source. Für geschäftsnahes Alerting — etwa ein Bestelleinbruch oder ein fehlgeschlagener Workflow — reicht oft eine No-Code-Automatisierung mit n8n, die eine Schwelle überwacht und ins Team meldet. Entscheidend ist nicht das Tool, sondern dass die Alerts handlungsleitend sind und bei einem wachen Menschen ankommen.

Soll ich auf Symptome oder auf Ursachen alarmieren?
Auf Symptome. „Kunden können nicht bezahlen" ist ein nützliches Alert, weil es eine echte Auswirkung beschreibt. „CPU bei 85 Prozent" ist oft nur eine Zahl — solange der Shop normal läuft, ist hohe Auslastung kein Grund, jemanden zu wecken. Symptom-basiertes Alerting fängt auch Fehler, an die beim Einrichten niemand gedacht hat.