# Monitoring-Alerts in Slack, Teams & per Webhook einrichten

> Einrichtung pro Kanal, Slack, Microsoft Teams, Webhook, plus die Webhook-Payload-Struktur (JSON) für eigene Pipelines. Mit Beispielen.

Source: https://uptimeify.io/de/blog/monitoring-alerts-slack-teams-webhook

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.

- **Ein Alarm ist nur so gut wie der Kanal, an dem er ankommt**. E-Mail allein wird oft zu spät gesehen.
- **Slack & Teams** bringen den Alarm dorthin, wo das Team ohnehin arbeitet, sofort sichtbar, im Kontext.
- **Webhooks** speisen den Alarm in eigene Pipelines: Ticketsystem, Automatisierung, eigenes Dashboard.
- **Der Payload ist frei baubar:** ein JSON-Template mit Platzhaltern wie `{{websiteName}}`, `{{status}}`, `{{errorMessage}}`.
- **Testen vor dem Ernstfall:** eine Testauslösung zeigt, ob Zustellung und Format stimmen, bevor der erste echte Alarm kommt.

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

Erkennung und Zustellung sind zwei Hälften desselben Werts. Ein präzise erkannter Ausfall nützt nichts, wenn der Alarm in einem selten geöffneten Postfach landet. Der richtige Kanal bringt ihn dorthin, wo die Aufmerksamkeit ohnehin ist.

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

Slack und Teams folgen demselben Prinzip: einen Incoming-Webhook für den Ziel-Channel erzeugen und dessen URL im Monitoring als Kanal hinterlegen. Ein dedizierter `#alerts`-Channel hält die Alarme sichtbar und frei von Rauschen.

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

Ein Webhook ist ein HTTP-Request an eine URL deiner Wahl, der Universaladapter, um Alarme in Ticketsysteme, Automatisierungen oder eigene Dashboards einzuspeisen. Konfigurierbar mit Methode, Headern, Timeout, Retries und erwarteten Statuscodes.

## 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:

```json
{
  "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:

```bash
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.

Der Webhook-Body ist ein frei baubares JSON-Template mit Platzhaltern wie `{{websiteName}}`, `{{status}}`, `{{startedAt}}` und `{{errorMessage}}`. So passt du den Alarm an das Format deines empfangenden Systems an, statt an ein festes Format gebunden zu sein.

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

Damit du dich im Ernstfall auf deine Kanäle verlassen kannst, solltest du sie vorher testen. Sieh dir an, wie sich Slack-, Teams- und Webhook-Zustellung prüfen und mit Wiederholungen absichern lassen.

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

Kanäle beantworten „wohin?", Eskalation beantwortet „was, wenn niemand reagiert?". Staffle ruhige Kanäle (Slack) auf frühen Stufen, aufdringliche (SMS) auf späten, und lass einen Webhook parallel laufen, um Alarme unabhängig von der menschlichen Reaktion zu verarbeiten.

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

Schließ die Lücke zwischen erkanntem Ausfall und richtiger Reaktion. Sieh dir an, wie Uptimeify bestätigte Alarme nach Slack, Teams und per Webhook in deine Pipeline routet, mit frei baubarem Payload und Testfunktion.