Uptimeify Docs

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:

  1. 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.
  2. Öffne den Tab Payload Mapping der Source und bearbeite die Selektoren: Füge severity-, host- und dedupKey-Selektoren hinzu, die auf die tatsächlichen Feldnamen deiner Payload zeigen (Dot-/Bracket-Pfade wie data.host.name oder alerts[0].id werden unterstützt, ebenso a || b-Fallback-Ketten für Felder, die nicht immer vorhanden sind). Füge bei Bedarf ein severityMap hinzu, falls dein Tool ein eigenes Schweregrad-Vokabular sendet, damit es auf Uptimeifys Skala sev1 bis sev4 abgebildet wird.
  3. 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.

Standard-Feld-Mapping

SelektorNormalisiertes FeldHinweise
title || messageTitelVersucht zuerst title, dann message
statusStatus: Werte in resolveValues lösen den Alarm auf, alles andere hält ihn offenStandard-resolveValues: resolved, closed
(standardmäßig keiner)SchweregradJeder Alarm nutzt den in der Source konfigurierten Standard-Schweregrad, bis du einen severity-Selektor und ein severityMap hinzufügst
(standardmäßig keiner)HostLeer, bis du einen host-Selektor hinzufügst
(standardmäßig keiner)Dedup-KeyFä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.

Auf dieser Seite