Dringende Anfragen, die in Slack untergehen, kenne ich aus eigener Erfahrung nur zu gut: ein Ping im falschen Kanal, ein Bot, der eine Meldung verschluckt, oder eine Zuständigkeit, die nicht klar ist — und plötzlich dauert eine Lösung viel zu lange. Aus diesen Situationen heraus habe ich eine einfache, praxistaugliche Eskalationskette entwickelt, die sich in Slack abbilden lässt. Im Folgenden erkläre ich, wie Sie in fünf Schritten eine zuverlässige Eskalationskette einrichten, damit dringende Anfragen nicht mehr verlorengehen.
Schritt: Kriterien und Verantwortlichkeiten definieren
Bevor ich irgendwelche technischen Einstellungen vornehme, definiere ich klar, was dringend bedeutet. Ohne ein gemeinsames Verständnis bleiben Eskalationen willkürlich und frustrieren das Team.
Typische Kriterien, die ich empfehle zu klären:
Parallel definiere ich die Rollen in der Eskalationskette: First Responder, Second Level, Verantwortliche/r Teamlead, und ggf. Management On-Call. Diese Rollen schreibe ich kurz und präzise auf, z. B. in einem Dokument in Confluence oder einem gepinnten Slack-Post.
Schritt: Kanalstruktur und Benennungsregeln anlegen
Eine saubere Kanalstruktur in Slack ist Gold wert. Ich lege spezielle Kanäle für dringende Vorfälle an und etabliere klare Benennungsregeln, zum Beispiel:
Wichtig ist, dass diese Kanäle sichtbar und abonniert sind von denen, die im Ernstfall reagieren müssen. Ich pinne außerdem ein kurzes Escalation-Playbook in jedem Kanal: Wer ist First Responder? Welche Reaktionszeit gilt? Wer wird als Nächstes informiert?
Schritt: Automatisierte Alerts und Trigger konfigurieren
Manuelle Pings funktionieren selten zuverlässig rund um die Uhr — deshalb nutze ich Automatisierung. Das kann nativ in Slack stattfinden (z. B. mit dem Workflow Builder) oder über Integrationen wie PagerDuty, Opsgenie, Zapier oder Monitoring-Tools wie Datadog und Prometheus.
Meine typische Vorgehensweise:
Beispiel mit Workflow Builder: Ein Formular (Slash-Command oder Workflow-Form) für "Dringender Vorfall" fragt kurz ab: Betroffene Anwendung, Dringlichkeit (P0–P3), Kurzbeschreibung. Workflow postet strukturierte Nachricht in #inc-xyz und taggt die Rolle @onsupport-first.
Schritt: Eskalationsrichtlinien und On-Call-Rotation abbilden
Eine Meldung im Kanal reicht nicht — sie muss jemanden erreichen, der darauf antwortet. Hier setze ich auf klare Eskalationsregeln und On-Call-Rotationen.
Optionen, die ich nutze:
Ich lege eine einfache Eskalationsmatrix an — das ist praktisch als Tabelle und wird in jedem Incident-Kanal verlinkt (siehe Beispiel unten).
| Level | Rolle | Reaktion | Escalation nach |
|---|---|---|---|
| 1 | First Responder (@onsupport-first) | Acknowledge in 10 min, Initial assessment | 10 min |
| 2 | Second Level (@dev-oncall) | Troubleshoot, Hotfix | 20 min |
| 3 | Teamlead (@lead-team) | Koordination, Kommunikation nach außen | 45 min |
| 4 | Management On-Call | Entscheidungen, Ressourcenfreigabe | 90 min |
Schritt: Tests, Dokumentation und regelmäßige Reviews
Eine Eskalationskette lebt — sie muss getestet und angepasst werden. Ich plane deshalb regelmäßige Tests und Retrospektiven ein.
Wichtig ist auch die Dokumentation für neue Teammitglieder: ein kurzes Onboarding-Video oder eine Seite "How to handle an incident in Slack" spart enorm Zeit.
Praktische Tipps und Fallstricke
Aus meinen Tests und aus Gesprächen mit anderen Praktikern habe ich ein paar konkrete Empfehlungen zusammengetragen:
Wenn Sie möchten, kann ich Ihnen eine Slack-Message-Vorlage und ein Beispiel-Workflow-JSON für den Slack Workflow Builder bereitstellen, das Sie direkt importieren und anpassen können. Sagen Sie mir kurz, welche Tools Sie bereits nutzen (z. B. PagerDuty, Datadog, Zapier), dann mache ich die Vorlage spezifisch für Ihre Umgebung.