Ein Alarm schlägt an – aber niemand reagiert. Die zuständige Person schläft, hat keinen Empfang oder hat die Benachrichtigung übersehen. Fünf Minuten vergehen, zehn, fünfzehn. Der Dienst ist weiterhin ausgefallen. Was in diesem Szenario fehlt, ist keine bessere Monitoring-Konfiguration, sondern eine funktionierende Eskalationsrichtlinie.
Eskalationsrichtlinien sind das Herzstück jedes On-Call-Systems. Sie definieren, was passiert, wenn eine Benachrichtigung nicht bestätigt wird: Wer wird als Nächstes alarmiert? Nach welcher Frist? Über welchen Kanal? Gut durchdachte Richtlinien verkürzen die Time-to-Response erheblich – und entlasten gleichzeitig die Teams, weil sie die Koordination im Ernstfall automatisieren.
Was eine Eskalationsrichtlinie konkret definiert
Eine Eskalationsrichtlinie besteht aus mehreren Eskalationsstufen. Jede Stufe beschreibt drei Kernelemente:
- Wen alarmieren: Eine konkrete Person, eine On-Call-Rotation oder ein ganzes Team
- Über welchen Kanal: Push-Benachrichtigung, SMS, Telefonanruf oder E-Mail
- Wie lange warten: Die Timeout-Frist, nach der zur nächsten Stufe eskaliert wird
Typisch ist ein dreistufiges Schema: Stufe 1 alarmiert den primären On-Call-Dienst. Bestätigt dieser innerhalb von 5 Minuten nicht, wird Stufe 2 ausgelöst – der Backup-Dienst. Bleibt auch dieser stumm, erreicht Stufe 3 den Team-Lead oder Engineering-Manager. Das stellt sicher, dass kein Incident dauerhaft unbearbeitet bleibt.
Warum Timeouts präzise definiert sein müssen
Ein häufiger Fehler: Eskalations-Timeouts sind zu lang. 15 oder 20 Minuten klingen moderat, sind aber für einen Produktionsausfall eine Ewigkeit. Eine E-Commerce-Plattform verliert bei jeder Minute Downtime echten Umsatz. Ein SaaS-Dienst mit einem SLA von 99,9 % hat pro Monat nur 43,8 Minuten Downtime-Budget insgesamt.
Timeouts sollten nach Severity gestaffelt sein. Ein kritischer Incident, bei dem ein Dienst komplett ausgefallen ist, rechtfertigt eine Eskalation nach 3–5 Minuten. Ein niedrig priorisierter Alert – etwa wenn der Speicher bei 80 % liegt – kann 15–30 Minuten warten. Die Kopplung von Alert-Severity und Eskalations-Timeout ist eine der wichtigsten Stellschrauben im On-Call-Design und sollte bewusst konfiguriert werden.
Rotationen und Eskalationsrichtlinien sauber trennen
On-Call-Rotationen und Eskalationsrichtlinien sind verwandte, aber verschiedene Konzepte. Eine Rotation legt fest, wer wann Dienst hat – etwa eine wöchentliche Rotation zwischen vier Ingenieuren. Eine Eskalationsrichtlinie legt fest, was passiert, wenn diese Person nicht reagiert.
Beides getrennt zu konfigurieren hat klare Vorteile: Die Rotation ändert sich regelmäßig, die Eskalationslogik bleibt stabil. Wenn in Woche 4 Person A Dienst hat, zeigt die Eskalationsrichtlinie auf „aktueller primärer On-Call" – automatisch Person A, ohne die Richtlinie manuell anpassen zu müssen. Werkzeuge wie PagerDuty, Opsgenie oder FreshCore unterstützen diese Trennung durch eigene Rotations- und Policy-Konzepte, die sauber miteinander verknüpft werden können.
Kanalwahl: SMS, Anruf oder Push?
Nicht alle Benachrichtigungskanäle sind gleich zuverlässig oder gleich aufdringlich. In der Praxis hat sich folgendes Stufenmodell bewährt:
- Push-Benachrichtigungen eignen sich für erste Alarme tagsüber – schnell, leise und direkt auf dem Sperrbildschirm sichtbar.
- SMS sind zuverlässiger als Push bei instabilem Internet oder deaktivierten App-Benachrichtigungen, ohne dabei so aufdringlich wie ein Anruf zu sein.
- Telefonanrufe sind für kritische Eskalationsstufen am wirkungsvollsten – sie wecken auf, durchdringen andere Aktivitäten und sind schwer zu übersehen.
Eine bewährte Strategie kombiniert alle drei Kanäle: Stufe 1 via Push-Benachrichtigung, Stufe 2 via SMS, Stufe 3 via Telefonanruf. Das schafft eine Intensitätskurve, die sowohl schlafende Personen nachts zuverlässig erreicht als auch Alert-Fatigue bei tagsüber aktiven Teams minimiert.
Alert-Fatigue durch kluge Eskalationslogik vermeiden
Wer zu viele Alerts empfängt, die selten kritisch sind, beginnt unbewusst, Benachrichtigungen zu ignorieren. Das Phänomen Alert-Fatigue ist gut dokumentiert und hat direkte Auswirkungen auf die Reaktionszeit bei echten Incidents. Die Gefahr ist real: Ein Team, das täglich 50 harmlose Alerts bekommt, reagiert auf den 51. – den kritischen – langsamer oder gar nicht.
Eskalationsrichtlinien können Alert-Fatigue reduzieren, wenn sie konsequent nach Severity differenzieren. Niedrigpriorisierte Alerts sollten nachts nicht eskalieren. Duplikatsmeldungen desselben Problems sollten gruppiert werden. Und Alerts, die seit Wochen nie bestätigt werden, müssen hinterfragt werden – oft ist der Check falsch konfiguriert oder der Schwellenwert zu aggressiv gesetzt. Teams, die ihre Eskalationsrichtlinien regelmäßig in On-Call-Reviews auswerten, reduzieren ihre Alarm-Menge signifikant ohne Abstriche bei der echten Erkennungsleistung.
Eskalationsrichtlinien testen, bevor der Ernstfall eintritt
Eine ungetestete Eskalationsrichtlinie ist eine falsche Sicherheit. Regelmäßige Tests sind deshalb entscheidend – mindestens einmal im Quartal sollte ein simulierter Incident die gesamte Eskalationskette auslösen. Dabei prüft man:
- Erhalten alle Stufen die Benachrichtigung?
- Sind Timeouts realistisch konfiguriert und ausreichend kurz?
- Haben alle Personen in der Rotation aktuelle Kontaktdaten hinterlegt?
- Funktioniert die Quittierungslogik in allen genutzten Kanälen?
Tests aufzuzeichnen und in Postmortems zu referenzieren hilft, blinde Flecken systematisch zu finden. Ein Eskalations-Test dauert selten mehr als 15 Minuten – und kann im Ernstfall Stunden einsparen.
Granulare Richtlinien: Nicht eine Eskalationskette für alles
Größere Teams mit mehreren Services profitieren von differenzierten, service-spezifischen Eskalationsrichtlinien. Die Datenbankinfrastruktur hat andere primäre Ansprechpartner als das Frontend oder die Payment-Integration. Wenn ein kritischer Datenbankfehler nach drei Eskalationsstufen beim Frontend-Lead landet, verschwendet man wertvolle Zeit.
Moderne On-Call-Systeme erlauben service-spezifische Richtlinien: Alert-Gruppen werden bestimmten Teams zugeordnet, Teams haben eigene Eskalationsketten. Das bedeutet mehr Konfigurationsaufwand initial – zahlt sich aber bei Incidents aus, wenn sofort die richtige Expertise alarmiert wird und keine manuelle Koordination zwischen Teams notwendig ist.
Fazit: Eskalationsrichtlinien sind Incident-Response-Infrastruktur
Eine robuste Eskalationsrichtlinie ist kein Nice-to-have, sondern strukturelle Incident-Response-Infrastruktur. Sie automatisiert die Koordination im Ernstfall, reduziert die Zeit bis zur ersten Reaktion und entlastet Teams von manueller Orchestrierung unter Stress. Wer Eskalationsrichtlinien nach Severity staffelt, regelmäßig testet und konsequent mit On-Call-Rotationen verknüpft, hat eine der wichtigsten Grundlagen für zuverlässigen IT-Betrieb gelegt.
Bildquelle: NERSC / U.S. Department of Energy / Wikimedia Commons, Public Domain
Quellen
- PagerDuty: Best Practices for On-Call and Alerting (pagerduty.com)
- Google SRE Book: Being On-Call (sre.google)
- Atlassian: Incident Management Handbook (atlassian.com)
