---
title: "Aufbewahrung (Retention)"
description: "Wie lange Incident Management rohe Alert-Payloads, gelöste Alerts und Outbound-Zustellprotokolle aufbewahrt — und was unbegrenzt erhalten bleibt."
---

Incident Management bewahrt verschiedene Teile der Historie eines Incidents unterschiedlich lange auf. Kurz gesagt: Der Incident-Datensatz selbst und seine aggregierte Historie sind dauerhaft; das rohe, potenziell sensible Rohmaterial dahinter nicht.

| Daten | Aufbewahrung |
|---|---|
| Roh-Payload eines Alerts (`im_alert.rawPayload`) | 90 Tage nach Aufnahme genullt |
| Gelöste Alerts (die `im_alert`-Zeile selbst) | 90 Tage nach Aufnahme gelöscht |
| Outbound-Zustellprotokolle (Historie der Integrations-Weiterleitung) | 90 Tage nach Versand gelöscht |
| Tägliche Aggregate pro Source (Alert-/Dedup-/Incident-Zähler) | Unbegrenzt erhalten |
| Incidents, Timeline-Events, Zuweisungen | Unbegrenzt erhalten |

## Warum der Roh-Payload genullt wird, nicht der Alert

`rawPayload` ist der exakte, unveränderte Body, den deine Source gesendet hat — der Webhook eines Anbieters kann API-Keys oder andere Geheimnisse enthalten, die dessen Betreiber hineingelegt hat. Das ist nichts, das auf ewig aufbewahrt werden sollte, nur weil der daraus entstandene Alert noch relevant ist. `mappedFields` — die bereits normalisierte, sichere Sicht, auf die derselbe Payload abgebildet wird (Titel, Severity, Host usw.) — ist getrennt von `rawPayload` und überlebt es; [Incident abrufen](/de/api/incident-management/get-incident) liefert immer `mappedFields`, nie `rawPayload`, unabhängig vom Alter.

## Warum Aggregate die Zeilen überleben, aus denen sie berechnet werden

Die täglichen Zähler einer Source (im Analytics-Tab sichtbar) werden unbegrenzt aufbewahrt — genau damit das Löschen der zugrunde liegenden gelösten Alert-Zeilen nach 90 Tagen nicht auch deine längerfristige Historie darüber löscht, wie sich eine Source oder ein Team entwickelt. Den einzelnen Alert verlierst du, sobald er verfällt; die Form des Trends behältst du.