---
title: "Retention"
description: "How long Incident Management keeps raw alert payloads, resolved alerts, and outbound-delivery records — and what's kept indefinitely."
---

Incident Management retains different pieces of an incident's history for different lengths of time. In short: the incident record itself and its aggregate history are permanent; the raw, potentially sensitive material behind it is not.

| Data | Retention |
|---|---|
| Alert raw payload (`im_alert.rawPayload`) | Nulled out 90 days after ingest |
| Resolved alerts (the `im_alert` row itself) | Deleted 90 days after ingest |
| Outbound-delivery records (integration forwarding history) | Deleted 90 days after they were sent |
| Per-source daily aggregates (alert/dedup/incident counts) | Retained indefinitely |
| Incidents, timeline events, assignments | Retained indefinitely |

## Why the raw payload is nulled, not the alert

`rawPayload` is the exact, unmodified body your source sent — a vendor's webhook can carry API keys or other secrets its operator put in it, so it isn't something to keep around forever just because the alert it produced still matters. `mappedFields` — the already-normalized, safe view the same payload maps onto (title, severity, host, etc.) — is separate from `rawPayload` and survives it; [Get Incident](/api/incident-management/get-incident) always returns `mappedFields`, never `rawPayload`, regardless of age.

## Why aggregates outlive the rows they're computed from

A source's daily counts (shown on its Analytics tab) are retained indefinitely specifically so that deleting the underlying resolved-alert rows after 90 days doesn't erase your longer-term history of how a source or team is trending. You lose the individual alert once it ages out; you keep the shape of the trend.