---
title: "Benutzerdefinierter Webhook"
description: "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.

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

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

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