Uptimeify Docs
MonitoringIncident Management

Retention

How long Incident Management keeps raw alert payloads, resolved alerts, outbound-delivery records and the incidents themselves, and what's kept indefinitely.

Incident Management retains different pieces of an incident's history for different lengths of time. In short: the per-source daily aggregates are permanent, an incident keeps its full detail for a year and lives on as a daily aggregate for a second year, and the raw, potentially sensitive material behind it goes sooner than either.

DataRetention
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
Incidents, timeline events, assignmentsDeleted 12 months after the incident was triggered
Daily incident aggregate (volume, MTTA, MTTR per day, team and severity)Deleted 24 months after the day it covers
Per-source daily aggregates (alert/dedup/incident counts)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 is the already-normalized, safe view the same payload maps onto (title, severity, host, etc.). It is separate from rawPayload and survives it; 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.

Why incidents keep 12 months of detail and 24 months of shape

The same idea applied to incidents, one step at a time. For twelve months an incident is kept whole: its timeline, its assignments and the alerts it was built from, so a quarterly review, an annual report or an audit finds the real thing rather than a summary of it. That is twice the six-month window most incident tools open by default.

Past twelve months the question people actually ask changes from "what happened in this incident" to "what did last year look like", and that question is answered by one row per day, team and severity carrying the volume, the acknowledgement latency and the resolution latency. Those rows are written nightly, before anything is deleted, and nothing is ever removed that they have not already recorded. They are kept for 24 months, so a year-over-year comparison always has both years in it.

Two consequences worth knowing. An incident older than twelve months disappears from the incident list and from the API, including one that was somehow never resolved: the window is a clock, not a status. And percentiles cannot be recomputed from the aggregate, only totals and averages, so a report older than twelve months shows mean time to acknowledge and mean time to resolve rather than a p95.

On this page