---
title: "Prometheus Alertmanager"
description: "Prometheus-Alertmanager-Benachrichtigungen über einen Webhook-Receiver an Uptimeify Incident Management senden, abgebildet aus commonLabels und dem ersten Alarm."
---

Uptimeify bildet mit dem Alertmanager-Preset die `webhook_config`-Benachrichtigungs-Payload des Alertmanagers direkt ab: Zusammenfassung/Alarmname, Schweregrad-Label, Status und Instanz sind bereits vorab gemappt.

## 1. Alert Source in Uptimeify anlegen

Gehe zu **Incident Management → Alert Sources → Neu**, wähle das **Prometheus Alertmanager**-Preset, 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. Webhook-Receiver im Alertmanager anlegen

Füge deiner `alertmanager.yml` einen Receiver hinzu, der auf die Ingest-URL zeigt:

```yaml
receivers:
  - name: uptimeify
    webhook_configs:
      - url: "https://deine-domain/api/im/ingest/<token>"
        send_resolved: true
```

`send_resolved: true` ist erforderlich. Ohne diese Option ruft der Alertmanager den Webhook nie auf, wenn sich ein Alarm auflöst. Incidents in Uptimeify blieben dann dauerhaft offen, selbst nachdem das zugrunde liegende Problem behoben ist.

## 3. Alarme zum Receiver routen

Referenziere den Receiver über eine Route in derselben Datei (entweder als Standard-Route oder als verschachtelte Route mit Label-Matcher):

```yaml
route:
  receiver: uptimeify
  # ...bestehender Routing-Baum, oder eine verschachtelte `routes:`-Regel statt der Default-Route
```

Lade den Alertmanager neu oder starte ihn neu, damit die Konfigurationsänderung greift (ein vorheriges `amtool check-config` ist eine sinnvolle Kontrolle).

## Standard-Feld-Mapping

Der Alertmanager gruppiert mehrere aktive Alarme in eine Benachrichtigung; das Preset liest Titel und Instanz aus dem **ersten Alarm** (`alerts[0]`) dieser Gruppe, den Schweregrad aus den gruppenweiten `commonLabels`:

| Alertmanager-Feld | Normalisiertes Feld |
|---|---|
| `alerts[0].annotations.summary` (Fallback auf `commonLabels.alertname`) | Titel |
| `commonLabels.severity` | Schweregrad (über die Zuordnung unten) |
| `status` (oberste Ebene) | Status: `resolved` löst den Alarm auf, alles andere (typischerweise `firing`) hält ihn offen |
| `alerts[0].labels.instance` | Host |
| `alerts[0].fingerprint` | Dedup-Key: der Alertmanager-eigene stabile Fingerabdruck pro Alarm |

### Schweregrad-Zuordnung

Das funktioniert nur, wenn deine Alarmregeln ein `severity`-Label setzen:

| Alertmanager-Label `severity` | Uptimeify-Schweregrad |
|---|---|
| `critical` | `sev1` |
| `warning` | `sev3` |
| `info` | `sev4` |

Jeder andere Wert oder ein fehlendes `severity`-Label fällt auf den in der Source konfigurierten Standard-Schweregrad zurück. Es gibt keine `sev2`-Zuordnung für den Alertmanager, da dessen eigene Schweregrad-Konvention meist nur `critical`/`warning`/`info` kennt.

## Beispiel-Payload

So sieht die Payload aus, die das Alertmanager-Preset von Uptimeify erwartet:

```json
{
  "version": "4",
  "groupKey": "{}:{alertname=\"InstanceDown\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "uptimeify-webhook",
  "groupLabels": { "alertname": "InstanceDown" },
  "commonLabels": { "alertname": "InstanceDown", "severity": "critical", "job": "node" },
  "commonAnnotations": { "summary": "Instance 10.0.0.5:9100 down" },
  "externalURL": "http://alertmanager.example.com:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "InstanceDown", "severity": "critical", "instance": "10.0.0.5:9100", "job": "node" },
      "annotations": { "summary": "Instance 10.0.0.5:9100 down", "description": "10.0.0.5:9100 has been down for more than 5 minutes." },
      "startsAt": "2026-07-17T12:00:00.000Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus.example.com:9090/graph?g0.expr=up%7Bjob%3D%22node%22%7D+%3D%3D+0",
      "fingerprint": "5b6e6e8f7a1c9d3e"
    }
  ]
}
```

Du kannst genau diese Payload über den Tab **Payload Mapping** im Dashboard gegen das Mapping deiner Source senden, um den Aufbau zu prüfen, bevor du den Alertmanager mit dem echten Receiver neu lädst.