Sequentielle Eskalationsstufen
Fügen Sie so viele Stufen hinzu, wie Ihr Team benötigt. Jede Stufe hat ihre eigenen Ziele und ihr eigenes Timeout-Fenster. Die Richtlinie schreitet automatisch voran, wenn keine Bestätigung rechtzeitig eingeht.
Eskalationsrichtlinien
Weiter eskalieren, bis
Weiter eskalieren, bis
jemand antwortet.
Definieren Sie schrittweise Richtlinien, die Person A benachrichtigen, warten, dann Person B benachrichtigen, dann das ganze Team — bis jemand bestätigt. Pro-Service- Richtlinien, Multi-Channel, mit konfigurierbaren Timeouts auf jeder Stufe.
Free tier included
No credit card
2-minute setup
payments-svc policy EscalatingLIVE
CURRENT LEVEL2 of 3
TIMEOUT5 min
ACKNOWLEDGEDNo
Level 1 — On-call (notified)100ms
Level 2 — Lead (notifying)80ms
Level 3 — Whole team60ms
Repeat 1×40ms
—8ms
Was Sie erhalten
Ein Alert, der nicht aufgibt.
Kritische Alerts hören nicht nach einem Versuch auf. Eine Eskalationsrichtlinie arbeitet ihre Stufen methodisch durch — benachrichtigt jedes Ziel, wartet auf einen konfigurierbaren Timeout, dann geht sie weiter — bis der Incident bestätigt wird oder die Richtlinie sich wiederholt.
Timeout-Kontrolle pro Stufe
Legen Sie das Bestätigungsfenster unabhängig für jede Stufe fest — 5 Minuten für den Bereitschaftsingenieur, dann 10 Minuten für den Teamleiter, dann sofortiger Page an das gesamte Team.
Ziele: Nutzer oder Zeitpläne
Richten Sie jede Stufe auf eine bestimmte Person oder auf einen Rufbereitschafts-Zeitplan. Wenn ein Zeitplan anvisiert wird, wird der aktuelle Bereitschaftsresponder für diesen Zeitplan paginiert — wer auch immer das gerade ist.
Automatische Re-Eskalation
Konfigurieren Sie einen Wiederholungszähler, damit die gesamte Richtlinie neu startet, wenn alle Stufen ohne Bestätigung erschöpft sind. Kritische Alerts laufen weiter, bis jemand antwortet.
Pro-Service-Zuweisung
Jeder Service in Ihrem Katalog trägt seine eigene Eskalationsrichtlinie. Payments-Alerts werden an die Payments-Rufbereitschaft weitergeleitet; Platform-Alerts an das Platform-Team. Kein manuelles Routing.
Sichtbarkeit des Eskalationsstatus
Sehen Sie in Echtzeit im Incident-Datensatz, auf welcher Stufe sich eine aktive Eskalation befindet — welche Stufe ausgelöst wurde, wer benachrichtigt wurde, wer bestätigt hat und wie lange jeder Schritt dauerte.
01 · Nichts fällt durchs Raster
Schritt für Schritt, bis
Schritt für Schritt, bis
jemand abnimmt.
Die meisten Alerting-Tools senden eine einzige Benachrichtigung und betrachten das als erledigt. Eskalationsrichtlinien sind anders: Sie schreiten automatisch durch die Stufen vor, berücksichtigen Stille, bis der Incident bestätigt wird — oder bis das konfigurierte Wiederholungslimit erreicht ist.
- Wechselt nach einem unbestätigten Timeout zur nächsten Stufe
- Zielt auf Rufbereitschafts-Zeitpläne, sodass kein Name je fest kodiert ist
- Wiederholt die gesamte Richtlinie, wenn alle Stufen ohne Bestätigung erschöpft sind
payments-svc policy Level 2 ActiveLIVE
LEVEL 1 TIMEOUT5m — elapsed
LEVEL 2 TIMEOUT10m — running
INCIDENTS THIS WEEK3
L1 — on-call paged100ms
L1 — timeout elapsed85ms
L2 — lead paged70ms
L2 — awaiting ack50ms
L3 — team (pending)20ms
02 · Pro-Service, im Repo definiert
Eine Richtlinie pro Service,
Eine Richtlinie pro Service,
per API provisioniert.
Weisen Sie jedem Service in Ihrem Katalog eine andere Eskalationsrichtlinie zu und provisionieren Sie sie alle über die REST API. Fügen Sie die Aufrufe in ein Skript in Ihrem Repo ein und Pull Requests zeigen Ihnen genau, welche Services ihr Routing geändert haben — keine Überraschungen während eines Incidents.
- Jeder Service trägt seine eigene Richtlinie — keine gemeinsamen Defaults
- Richtlinien über die REST API erstellt und versioniert
- Änderungen treten sofort in Kraft; kein Neustart erforderlich
create an escalation policy$ curl -X POST https://api.siteqwality.com/escalation_policy/ \
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"Payments SLA Policy","repeat":2,"levels":[{"timeout_minutes":5,"target":"schedule:payments-oncall"},{"timeout_minutes":10,"target":"user:payments-lead"},{"timeout_minutes":5,"target":"team:payments"}]}'
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"Payments SLA Policy","repeat":2,"levels":[{"timeout_minutes":5,"target":"schedule:payments-oncall"},{"timeout_minutes":10,"target":"user:payments-lead"},{"timeout_minutes":5,"target":"team:payments"}]}'
N+1
Stufen pro Richtlinie — so viele wie Ihr Team benötigt
0
verlorene Alerts — Richtlinie wiederholt sich bis zur Bestätigung
5m
minimaler konfigurierbarer Timeout zwischen Eskalationsstufen
$0
kostenloser Tarif — Eskalationsrichtlinien von Anfang an inklusive
FAQ
Questions, answered.
Es gibt kein festes Limit für die Anzahl der Stufen. In der Praxis verwenden die meisten Teams zwei bis vier Stufen — Bereitschaftsingenieur, Teamleiter, dann das gesamte Team — aber Sie können so viele hinzufügen, wie Ihre betrieblichen Anforderungen verlangen.
Wenn eine Richtlinie mit einem Wiederholungszähler größer als null konfiguriert ist, startet sie von Stufe eins neu und arbeitet die Stufen erneut durch. Dies setzt sich fort, bis das Wiederholungslimit erreicht ist oder jemand den Incident bestätigt.
Ja — und das ist der empfohlene Ansatz. Richten Sie eine Stufe auf einen Rufbereitschafts-Zeitplan aus und Site Qwality bestimmt, wer bei Auslösung der Stufe gerade im Dienst ist. Sie müssen die Richtlinie nie aktualisieren, wenn sich Rotationen ändern.
Eskalation respektiert die persönlichen Benachrichtigungsregeln jedes Teammitglieds. Wenn ein Responder SMS für dringende Alerts und Slack für niedrig priorisierte konfiguriert hat, wird diese Präferenz berücksichtigt, wenn die Eskalationsrichtlinie ihn paginiert.
Ja — das ist der Sinn und Zweck. Jedem Service in Ihrem Katalog wird seine eigene Eskalationsrichtlinie zugewiesen. Payments kann eine strenge SLA-Richtlinie haben; ein internes Tool kann eine entspannte haben. Änderungen sind pro Service und treten sofort in Kraft.
More of the platform
Explore the rest of the platform
Bereit?
In unter einer Minute live gehen.
Jedes Produkt startet kostenlos — Uptime-Monitoring, Cron-Monitoring, Synthetisches Monitoring, Logs, RUM, Incidents und Statusseiten. Keine Kreditkarte erforderlich.