Monitoring-Alerts in Slack, Teams & per Webhook einrichten

Ein Monitoring, das Ausfälle erkennt, aber nur eine E-Mail an ein selten geöffnetes Postfach schickt, ist nur die halbe Miete. Der eigentliche Wert entsteht dort, wo der Alarm ankommt: im Channel, den dein Team ohnehin den ganzen Tag offen hat, oder in der Pipeline, die daraus automatisch ein Ticket macht. Alerts sind erst nützlich, wenn sie am richtigen Ort landen, und das heißt: in Slack, in Microsoft Teams oder per Webhook in deinem eigenen System. Dieser Artikel zeigt die Einrichtung pro Kanal und die Struktur der Webhook-Payload, mit der du Alarme in beliebige eigene Pipelines einspeist.

Warum der Kanal über den Wert eines Alarms entscheidet

Es lohnt sich, kurz beim Offensichtlichen zu verweilen, denn es wird überraschend oft unterschätzt: Ein Alarm hat nur dann einen Wert, wenn ihn jemand rechtzeitig sieht. Das Monitoring kann einen Ausfall in Sekunden erkennen und präzise bestätigen. Wenn die Meldung dann in einem Postfach landet, das erst am nächsten Morgen geöffnet wird, war die ganze Schnelligkeit umsonst. Die Erkennung ist die eine Hälfte; die Zustellung an den richtigen Ort ist die andere, gleich wichtige.

Der Standardweg, eine E-Mail an eine Adresse, hat genau hier seine Schwäche. E-Mail ist asynchron und leicht zu übersehen, besonders wenn viele davon eintreffen. In einem Team, das den ganzen Tag in Slack oder Teams arbeitet, ist eine E-Mail der Kanal, den man am seltensten in Echtzeit im Blick hat. Der Alarm konkurriert dort mit Newslettern, Rechnungen und automatischen Benachrichtigungen, und geht im Zweifel unter.

Die Lösung ist, den Alarm dorthin zu bringen, wo die Aufmerksamkeit ohnehin ist. Für die meisten Teams ist das ein Chat-Tool; für Automatisierungen ist es ein Webhook, der den Alarm direkt in ein System einspeist. Die richtige Kanalwahl verwandelt eine Meldung, die vielleicht gesehen wird, in eine, die garantiert an der richtigen Stelle auftaucht. Genau darum geht es bei der Einrichtung der Kanäle.

Slack & Teams: der Alarm im Arbeits-Chat

Für die meisten Agenturen ist ein Chat-Tool der natürlichste Ort für Monitoring-Alarme, weil das Team dort ohnehin den ganzen Tag präsent ist. Ein Alarm, der als Nachricht in einem Channel erscheint, wird sofort gesehen, kann direkt im Thread besprochen werden und steht im Kontext der übrigen Team-Kommunikation. Die Einrichtung folgt bei Slack und Microsoft Teams demselben Grundprinzip.

Der Kern ist ein Incoming Webhook auf Seiten des Chat-Tools. In Slack erzeugst du für den gewünschten Channel eine Incoming-Webhook-URL, eine spezielle Adresse, an die Nachrichten geschickt werden können, die dann in genau diesem Channel erscheinen. In Microsoft Teams funktioniert es analog über einen eingehenden Webhook (bzw. einen entsprechenden Connector) für den Ziel-Channel. Diese URL ist der Schlüssel: Wer sie hat, kann Nachrichten in den Channel posten.

Im Monitoring hinterlegst du diese URL als Benachrichtigungskanal, bei Uptimeify als einen der Kanäle vom Typ Slack bzw. Teams. Ab diesem Moment schickt das Monitoring jeden bestätigten Ausfall als Nachricht an diese URL, und sie erscheint im Channel. Ein praktischer Rat: Lege einen dedizierten Channel für Monitoring-Alarme an (etwa #alerts oder #monitoring), statt sie in einen allgemeinen Channel zu mischen. So bleiben die Alarme sichtbar und erzeugen keine Ermüdung in einem Channel, in dem auch anderes passiert. Für unterschiedliche Kunden oder Dringlichkeiten lassen sich mehrere Channels und damit mehrere Kanäle einrichten.

Der Webhook: Alarme in die eigene Pipeline

Slack und Teams decken den Fall ab, dass ein Mensch den Alarm sehen soll. Der generische Webhook deckt den mächtigeren Fall ab, dass ein System auf den Alarm reagieren soll. Ein Webhook ist im Kern nichts anderes als ein HTTP-Request, den das Monitoring bei einem Ausfall an eine von dir bestimmte URL schickt, und weil du sowohl die URL als auch den Inhalt kontrollierst, kannst du den Alarm in praktisch jedes System einspeisen.

Die Anwendungsfälle sind vielfältig. Der Webhook kann ein Ticket in deinem Helpdesk anlegen, sodass aus jedem Ausfall automatisch ein nachverfolgbarer Vorgang wird. Er kann eine Automatisierung auslösen, etwa in einem Workflow-Tool, die weitere Schritte anstößt. Er kann den Alarm in dein eigenes Dashboard oder deine eigene Datenbank schreiben, um ihn mit anderen Daten zu verknüpfen. Oder er kann einen Chat-Dienst ansteuern, den es nicht als fertigen Kanal gibt. Der Webhook ist der Universaladapter, der das Monitoring mit dem Rest deiner Werkzeuge verbindet.

Bei Uptimeify konfigurierst du den Webhook über die Eskalationskonfiguration: Du hinterlegst die Ziel-URL, die HTTP-Methode (POST, PUT oder PATCH), optionale Header und, der entscheidende Teil, den Body als Template. Dazu kommen praktische Feineinstellungen: ein Timeout, eine Anzahl von Wiederholungsversuchen mit definiertem Abstand, falls der Endpoint nicht sofort antwortet, und die erwarteten Statuscodes, die eine erfolgreiche Zustellung kennzeichnen. Damit ist der Webhook nicht nur ein „schick etwas raus", sondern eine robuste, konfigurierbare Zustellung.

Die Payload-Struktur: den JSON-Body selbst bauen

Der eigentliche Kern eines Webhooks, und der Teil, der die Tech-Spur interessiert, ist der Body: die Nutzdaten, die das Monitoring an dein System schickt. Und hier liegt die eigentliche Flexibilität: Du gibst kein festes Format vor, sondern baust den Body als Template mit Platzhaltern, die das Monitoring beim Auslösen mit den echten Werten des Ausfalls füllt.

Die verfügbaren Platzhalter decken die relevanten Informationen eines Vorfalls ab: {{websiteName}} (Name der betroffenen Seite), {{websiteUrl}} (deren URL), {{status}} (aktueller Status, etwa down oder up), {{startedAt}} (Zeitpunkt des Vorfallsbeginns), {{errorMessage}} (die Fehlermeldung, falls vorhanden) und {{incident}} (das Incident-Objekt mit weiteren Details). Aus diesen Bausteinen setzt du genau die Struktur zusammen, die dein empfangendes System erwartet.

Ein einfaches Body-Template könnte so aussehen:

{
  "text": "Ausfall erkannt: {{websiteName}} ({{websiteUrl}})",
  "status": "{{status}}",
  "startedAt": "{{startedAt}}",
  "error": "{{errorMessage}}"
}

Der große Vorteil dieses Ansatzes: Du bist nicht an das Format des Monitorings gebunden, sondern passt den Alarm an das Format deines Systems an. Erwartet dein Ticketsystem bestimmte Feldnamen, benennst du die Keys entsprechend. Braucht deine Automatisierung eine bestimmte Struktur, baust du sie genau so. So aktualisierst du beim Konfigurieren des Webhooks per PATCH auf die Eskalationskonfiguration die Ziel-URL, die Methode und dieses Body-Template in einem Schritt:

curl -X PATCH "https://uptimeify.io/api/escalation-config/1" \
  -H "Authorization: Bearer wsm_<dein-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "webhookUrl": "https://deine-pipeline.example/alerts",
    "webhookMethod": "POST",
    "webhookHeaders": { "Content-Type": "application/json" },
    "isActive": true
  }'

Weil du den Payload selbst definierst, wird der Alarm von einer starren Meldung zu einem strukturierten Datensatz, den deine eigenen Systeme direkt weiterverarbeiten können. Genau das macht den Webhook zur Grundlage für echte Automatisierung statt bloßer Benachrichtigung.

Testen und Zustellung absichern

Ein Kanal, den man nie ausprobiert hat, ist eine Vermutung, keine Absicherung. Das gilt für Webhooks und Chat-Kanäle genauso wie für eine Eskalationskette. Der schlechteste Zeitpunkt, um festzustellen, dass ein Webhook eine falsche URL hat oder das JSON-Template einen Tippfehler enthält, ist der erste echte Ausfall. Deshalb gehört ein Test vor die Inbetriebnahme.

Uptimeify bietet dafür eine Testfunktion für die Eskalationskonfiguration: Sie sendet einen Test-Webhook (oder wahlweise ein dediziertes PagerDuty- bzw. Pushover-Ereignis) an das konfigurierte Ziel und meldet das Ergebnis zurück, etwa, ob der Endpoint erreichbar war und mit einem erwarteten Statuscode geantwortet hat. So siehst du sofort, ob die Zustellung klappt und das Format stimmt, bevor du dich im Ernstfall darauf verlässt. Für einen schnellen Check kannst du die Ziel-URL im Test sogar temporär überschreiben, etwa auf einen Request-Inspector, um den tatsächlich gesendeten Payload einmal im Rohformat zu sehen.

Für den laufenden Betrieb sichern zwei Mechanismen die Zustellung ab. Erstens die Wiederholungen: Antwortet der Ziel-Endpoint nicht sofort, versucht das Monitoring die Zustellung erneut, mit einer konfigurierbaren Anzahl von Versuchen und einem definierten Abstand dazwischen. Ein kurzzeitig nicht erreichbares System führt so nicht gleich zum verlorenen Alarm. Zweitens die Alert-Historie: Jeder Zustellversuch wird protokolliert, mit Kanal-Typ (etwa slack, email, opsgenie), Status (sent oder failed) und Zeitstempel. So ist im Nachhinein lückenlos nachvollziehbar, ob und über welchen Kanal ein Alarm angekommen ist, ein wichtiger Beleg, wenn es einmal Diskussionen gibt.

Kanäle und Eskalation zusammendenken

Die Einrichtung einzelner Kanäle entfaltet ihre volle Wirkung erst im Zusammenspiel mit der Eskalation. Ein Kanal beantwortet die Frage „wohin geht der Alarm?"; die Eskalation beantwortet „was passiert, wenn niemand reagiert?". Zusammen ergeben sie ein Alerting, das sowohl sichtbar als auch verlässlich ist.

In der Praxis staffelt man die Kanäle nach Dringlichkeit über die Eskalationsstufen. Die erste Stufe nutzt einen ruhigen, integrierten Kanal, Slack oder Teams, der das Team erreicht, ohne es aus allem herauszureißen. Reagiert dort niemand innerhalb der definierten Frist, greift die nächste Stufe über einen aufdringlicheren Kanal, etwa SMS oder einen dedizierten Dienst wie PagerDuty oder Opsgenie. Der Webhook wiederum kann parallel auf jeder Stufe laufen, um den Alarm unabhängig von der menschlichen Reaktion in deine Pipeline zu schreiben, etwa um immer ein Ticket zu erzeugen, egal wer letztlich reagiert. Uptimeify unterstützt für dieses Routing viele Kanäle nebeneinander, sodass jede Stufe an den passenden gekoppelt werden kann.

So entsteht ein durchdachtes System aus wenigen Bausteinen: Slack für die schnelle Sichtbarkeit, ein Webhook für die automatische Verarbeitung, eine aufdringliche zweite Stufe als Sicherheitsnetz. Jeder Baustein tut genau eine Sache gut, und zusammen sorgen sie dafür, dass ein Ausfall nicht nur erkannt, sondern auch gesehen, verarbeitet und im Zweifel eskaliert wird.

Vom erkannten Ausfall zur richtigen Reaktion

Der Kern dieses Themas ist die Erkenntnis, dass Monitoring erst dann vollständig ist, wenn der erkannte Ausfall zuverlässig die richtige Reaktion auslöst. Die beste Erkennung der Welt verpufft, wenn der Alarm im falschen Kanal landet oder in einem starren Format ankommt, mit dem deine Systeme nichts anfangen können. Die Einrichtung der Kanäle ist deshalb kein Nebenschauplatz, sondern der Schritt, der aus einem Monitoring ein funktionierendes Frühwarnsystem macht.

Die drei Bausteine decken zusammen jeden Fall ab. Slack und Teams bringen den Alarm dorthin, wo Menschen ihn sofort sehen. Der Webhook mit frei baubarem Payload speist ihn dorthin, wo Systeme ihn automatisch verarbeiten. Und die Testfunktion samt Wiederholungen und Alert-Historie sorgt dafür, dass diese Zustellung nicht nur eingerichtet, sondern auch verlässlich ist. Alle drei laufen nach derselben ruhigen Grundlage: Bestätigung von mehreren EU-Standorten, bevor überhaupt ein Alarm ausgelöst wird, damit nur echte Ausfälle die Kanäle erreichen.

Am Ende geht es darum, die Lücke zwischen „das Monitoring hat es bemerkt" und „jemand oder etwas hat reagiert" zu schließen. Wer seine Kanäle bewusst einrichtet, den Chat für die Sichtbarkeit, den Webhook für die Automatisierung, den Test für die Gewissheit, macht aus einem Alarm, der vielleicht ankommt, einen, der garantiert die richtige Reaktion auslöst. Genau das ist der Unterschied zwischen einem Monitoring, das nur beobachtet, und einem, das wirkt.