---
title: "E-Mail"
description: "Leite Alarm-E-Mails aus jedem Monitoring-Tool, Ticketing-System oder Postfach an eine eigene Empfangsadresse weiter oder route sie dorthin. Uptimeify wandelt sie automatisch in Vorfälle um."
---

Die Alert Source **E-Mail** wandelt E-Mails, die du an eine eigene Empfangsadresse weiterleitest oder routest, automatisch in Vorfälle um. Nutze sie für jedes Monitoring- oder Alerting-Tool, das nur per E-Mail benachrichtigen kann (keine Webhook-Option), oder überall dort, wo Alarme ohnehin in einem Postfach landen: ein gemeinsames Ops-Postfach, ein Legacy-Paging-System, ein Anbieter, der nur E-Mail-Benachrichtigungen anbietet.

Anders als die Webhook-Presets auf den anderen Seiten dieses Abschnitts hat eine E-Mail-Source keine JSON-Payload. Sie liest Betreff und Klartext-Body der E-Mail mit einer eigenen Selektor-Sprache aus (siehe unten), nicht mit den Dot-/Bracket-`Selector`-Pfaden dieser anderen Anleitungen.

## 1. Alert Source in Uptimeify anlegen

Gehe zu **Incident Management → Alert Sources → Neu** und wähle die Option **E-Mail** (neben den Webhook-Presets), vergib einen Namen und lege die Source an. Kopiere auf dem Erfolgsbildschirm die Empfangsadresse. Sie hat die Form `<token>@ingest.uptimeify.io` und wird nur einmal angezeigt, danach nie wieder im Klartext. Solltest du sie verlieren, rotiere den Token im Tab **Einstellungen** der Source, um eine neue Adresse zu erhalten.

## 2. Deine Alarme an die Adresse schicken

Es gibt keinen festen Absender oder Anbieter. Alles, was eine Klartext-E-Mail zustellen kann, funktioniert:

- Trage die Adresse als Benachrichtigungs-/Kontaktziel in einem Monitoring-Tool ein, das nur E-Mail-Alerting unterstützt.
- Richte in deinem Postfach (Gmail, Outlook, ein gemeinsamer Ops-Alias, …) eine Weiterleitungsregel ein, die passende Alarm-E-Mails dorthin weiterleitet.
- Zeige eine bereits bestehende Mail-Routing-Regel oder ein Relay darauf, falls Alarme schon durch eines laufen.

Gelesen wird nur der **Klartext-Body**. Eine reine HTML-E-Mail ohne Klartext-Teil ergibt für die Selektoren einen leeren Body. Der Betreff steht weiterhin zur Verfügung.

## Standard-Feld-Mapping (ohne Konfiguration)

Eine frisch angelegte E-Mail-Source funktioniert ohne weitere Einrichtung mit diesen Vorgaben:

| Feld | Standardquelle | Hinweise |
|---|---|---|
| Titel | Betreff-Header, unverändert | |
| Status | `open`, außer der Betreff enthält als ganzes Wort `resolved`, `recovered` oder `cleared` (Groß-/Kleinschreibung egal) | Durchsucht wird dafür nur der **Betreff**, nie der Body, damit der Fließtext eines noch aktiven Alarms (z. B. „checks are not ok“) niemals als Auflösung missverstanden wird |
| Schweregrad | Der in der Source konfigurierte Standard-Schweregrad | Jede E-Mail nutzt ihn, bis du einen `severity`-Selektor + `severityMap` hinzufügst |
| Host | Leer | Bis du einen `host`-Selektor hinzufügst |
| Dedup-Key | Ein deterministischer Hash aus Titel + Absenderadresse | Bis du einen `dedupKey`-Selektor hinzufügst |

## Die E-Mail-Selektor-Sprache

E-Mail-Selektoren sind eine kleine, eigene Syntax, getrennt von den JSON-`Selector`-Pfaden der Webhook-Sources, denn eine E-Mail hat keine JSON-Struktur zum Durchlaufen:

| Selektor | Löst auf zu |
|---|---|
| `subject` | Der Betreff-Header der E-Mail, unverändert |
| `body` | Der Klartext-Body, unverändert |
| `body.line(N)` | Die N-te Zeile des Klartext-Bodys, 1-indiziert (`body.line(1)` ist die erste Zeile) |
| `subject =~ /muster/` | Regex-Match gegen den Betreff: die erste Capture-Gruppe `(...)`, falls das Muster eine hat, sonst der gesamte Match |
| `body =~ /muster/` | Dasselbe, gegen den Klartext-Body |

Ein Selektor kann per `||` Fallback-Ketten bilden, dieselbe Konvention wie bei den Webhook-`Selector`-Pfaden: Der erste Kandidat, der zu einem nicht-leeren Wert auflöst, gewinnt:

```
subject =~ /Status: (\w+)/ || body.line(1)
```

Ein fehlendes Feld, eine Zeilennummer außerhalb des gültigen Bereichs oder ein ungültiges bzw. nicht passendes Regex lösen alle zu „nichts“ auf, statt einen Fehler zu werfen. Eine fehlerhafte oder unerwartete E-Mail ist normaler, erreichbarer Input, kein Bug.

## Mapping anpassen

Im Dashboard gibt es aktuell keinen eigenen Mapping-Editor für E-Mail-Sources (der Selektor-Editor im Tab **Payload Mapping** zielt auf die JSON-Webhook-Form). Um Selektoren zu konfigurieren, nutzt du die API:

1. `GET /api/im/sources/:id`, um das aktuelle `payloadMapping` der Source zu lesen. Du brauchst das VOLLSTÄNDIGE Objekt zurück, nicht nur den Teil, den du änderst (siehe Warnhinweis unten).
2. `PATCH /api/im/sources/:id` mit dem vollständigen `payloadMapping`, in dem du einen `emailSelectors`-Schlüssel hinzufügst oder bearbeitest:

```bash
curl -X PATCH "https://deine-domain/api/im/sources/<id>" \
  -H "Content-Type: application/json" \
  -H "Cookie: <deine-session-cookie>" \
  -d '{
    "payloadMapping": {
      "title": "title",
      "severity": "severity",
      "severityMap": { "sev1": "sev1", "sev2": "sev2", "sev3": "sev3", "sev4": "sev4" },
      "status": "status",
      "resolveValues": ["resolved"],
      "host": "host",
      "dedupKey": "dedupKey",
      "emailSelectors": {
        "title": "subject",
        "severity": "subject =~ /\\[(CRITICAL|WARNING)\\]/",
        "severityMap": { "CRITICAL": "sev1", "WARNING": "sev3" },
        "resolveValues": ["resolved", "recovered", "cleared"]
      }
    }
  }'
```

<Callout type="warn">
  Ein `PATCH` **ersetzt den kompletten `payloadMapping`-Wert**, er wird nicht zusammengeführt. Sendest du nur `{ "payloadMapping": { "emailSelectors": {...} } }`, gehen die übrigen Felder (`title`, `severity`, `status`, `host`, `dedupKey`, `resolveValues`) verloren, die Uptimeifys Ingest-Pipeline intern braucht, und die Source ist dann kaputt. Schicke immer das vollständige Objekt zurück, ausgehend von einem frischen `GET`.
</Callout>

Das `emailSelectors`-Unterobjekt akzeptiert:

| Schlüssel | Typ | Zweck |
|---|---|---|
| `title` | Selektor | Standardmäßig `subject` |
| `severity` | Selektor | Roher Wert wird in `severityMap` nachgeschlagen |
| `severityMap` | Objekt | Bildet einen extrahierten Rohwert auf `sev1` bis `sev4` ab |
| `status` | Selektor | Falls gesetzt, wird der aufgelöste Wert gegen `resolveValues` geprüft; falls nicht gesetzt, greift stattdessen der oben beschriebene Betreff-Scan ohne Konfiguration |
| `resolveValues` | Array von Strings | Groß-/kleinschreibungsunabhängige Begriffe, die „aufgelöst“ bedeuten. Standard: `["resolved", "recovered", "cleared"]` |
| `host` | Selektor | |
| `dedupKey` | Selektor | Standardmäßig ein Hash aus Titel + Absenderadresse |
| `custom` | Objekt aus Selektoren | Zusätzliche Felder, genauso bereitgestellt wie das `custom`-Mapping einer Webhook-Source |

## Antwort

Jede E-Mail, die eine gültige Adresse erreicht, wird zur asynchronen Verarbeitung angenommen. Es gibt kein synchrones Erfolgs-/Fehler-Signal wie das `202 Accepted` eines Webhooks, da die Mailzustellung selbst der Transport ist. Eine E-Mail, deren Selektoren zu keinem Titel auflösen, wird verworfen (nichts, worauf man alarmieren könnte), statt einen leeren Vorfall zu erzeugen.