Benutzerdefinierter Webhook
Alarme aus jedem Tool, das JSON per POST senden kann, an Uptimeify Incident Management schicken, mit eigenem Feld-Mapping im Dashboard.
Das Preset Benutzerdefinierter Webhook ist der Ausgangspunkt für jedes Monitoring- oder Alerting-Tool, für das es kein eigenes Preset gibt: eine Firewall-Appliance, ein internes Skript, ein Nischen-SaaS-Produkt, alles, was eine HTTP-POST-Anfrage mit JSON-Body senden kann. Anders als die übrigen Presets kommt es nur mit einem minimalen Standard-Mapping. Den Rest legst du selbst fest, sobald du die tatsächliche Payload-Form deines Tools siehst.
1. Alert Source in Uptimeify anlegen
Gehe zu Incident Management → Alert Sources → Neu, wähle das Preset Benutzerdefinierter Webhook, vergib einen Namen und lege die Source an. Kopiere auf dem Erfolgsbildschirm die Ingest-URL (https://deine-domain/api/im/ingest/<token>). Sie wird nur einmal angezeigt und danach nie wieder im Klartext eingeblendet. Solltest du sie verlieren, rotiere den Token im Tab Einstellungen der Source.
2. Dein Tool auf die Ingest-URL zeigen lassen
Konfiguriere das Webhook-/Benachrichtigungsziel deines Tools so, dass es bei jedem ausgelösten oder aufgelösten Alarm eine HTTP-POST-Anfrage mit JSON-Body an die Ingest-URL sendet. Es gibt kein festes Request-Schema auf der Empfängerseite. Sende, was dein Tool liefert.
curl -X POST "https://deine-domain/api/im/ingest/<token>" \
-H "Content-Type: application/json" \
-d '{
"title": "Disk usage above 90% on db-primary",
"status": "open"
}'3. Feld-Mapping an deine Payload anpassen
Das Standard-Mapping extrahiert nur einen Titel und einen Status: sinnvolle Vorgaben für eine generische Payload, aber fast sicher nicht alles, was du möchtest:
- Sende einmal eine echte (oder repräsentative Test-)Payload aus deinem Tool, damit du die genauen Feldnamen siehst. Die Ansicht Live-Aktivität auf der Detailseite der Alert Source zeigt die zuletzt empfangenen Rohdaten.
- Öffne den Tab Payload Mapping der Source und bearbeite die Selektoren: Füge
severity-,host- unddedupKey-Selektoren hinzu, die auf die tatsächlichen Feldnamen deiner Payload zeigen (Dot-/Bracket-Pfade wiedata.host.nameoderalerts[0].idwerden unterstützt, ebensoa || b-Fallback-Ketten für Felder, die nicht immer vorhanden sind). Füge bei Bedarf einseverityMaphinzu, falls dein Tool ein eigenes Schweregrad-Vokabular sendet, damit es auf Uptimeifys Skalasev1bissev4abgebildet wird. - Speichern, und prüfe anschließend über das Testpanel im Tab Payload Mapping, ob eine Beispiel-Payload durch dein angepasstes Mapping die erwarteten Werte für Titel/Schweregrad/Status/Host liefert, bevor du dich bei echten Alarmen darauf verlässt.
Payloads ohne Statusfeld (Regex)
Manche Tools schicken nur Freitext: Beszel, der generische Webhook von Uptime Kuma, Healthchecks.io, Gatus. Es gibt kein Statusfeld und keine stabile Alarm-ID, und Alarm- und Entwarnungstitel unterscheiden sich. Jeder Selektor kann mit feld =~ /muster/ einen Wert aus Text schneiden, in derselben Schreibweise wie die E-Mail-Quelle. Der Wert ist die erste Klammergruppe, ohne Klammergruppe der ganze Treffer. Kein Treffer gilt als „nicht vorhanden“, dann greift der nächste Kandidat einer a || b-Kette. Erlaubt sind die Flags i, m, s und u; durchsucht werden die ersten 4.096 Zeichen eines Felds, und ein Muster, das eine selbst wiederholte Gruppe wiederholt ((a+)+), trifft nie.
Beispiel für Beszel (generischer Webhook, template=json), das {"title": "backend1 CPU above threshold", "message": "..."} schickt und bei der Entwarnung "backend1 CPU below threshold":
| Selektor | Wert |
|---|---|
title | title |
status | title =~ /(below threshold|is up)/ mit resolveValues: below threshold, is up |
dedupKey | title =~ /^(.+) (?:above|below) threshold$/ || title =~ /^Connection to (.+) is/ |
Alarm und Entwarnung teilen sich damit einen Dedup-Schlüssel (backend1 CPU, bei Verbindungsalarmen backend1), und die Entwarnung löst den Vorfall auf. Für Beszel selbst gibt es das fertige Beszel-Preset, das auch Container, Dienste, Akku, SMART und ZFS abdeckt.
Standard-Feld-Mapping
| Selektor | Normalisiertes Feld | Hinweise |
|---|---|---|
title || message | Titel | Versucht zuerst title, dann message |
status | Status: Werte in resolveValues lösen den Alarm auf, alles andere hält ihn offen | Standard-resolveValues: resolved, closed |
| (standardmäßig keiner) | Schweregrad | Jeder Alarm nutzt den in der Source konfigurierten Standard-Schweregrad, bis du einen severity-Selektor und ein severityMap hinzufügst |
| (standardmäßig keiner) | Host | Leer, bis du einen host-Selektor hinzufügst |
| (standardmäßig keiner) | Dedup-Key | Fällt auf einen deterministischen Hash aus Titel + Host zurück, bis du einen dedupKey-Selektor hinzufügst |
Beispiel-Payload
So sieht die Payload aus, die das Standard-Mapping direkt nach dem Anlegen erwartet:
{
"title": "Disk usage above 90% on db-primary",
"message": "Disk usage above 90% on db-primary",
"status": "open"
}Du kannst genau diese Payload über den Tab Payload Mapping im Dashboard gegen das Mapping deiner Source senden, eine gute Möglichkeit, das Standard-Mapping zu bestätigen, bevor du die Selektoren für dein echtes Tool anpasst.
Beszel
Beszel-Serveralarme über einen generischen Shoutrrr-Webhook an Uptimeify Incident Management senden, mit Host, Link, Schweregrad und automatischer Entwarnung für jeden Beszel-Alarmtyp.
Datadog
Datadog-Monitor-Alarme über eine Datadog-Webhook-Integration an Uptimeify Incident Management senden, bereits auf Titel, Alarmtyp und Übergangsstatus abgebildet.