Three different records#
| Record | What it captures |
|---|---|
| Raw event | The authenticated payload accepted from an integration, plus receipt and processing information. |
| Normalized alert and occurrence | The current monitoring condition and the history of observations that contributed to it. |
| Incident | The response lifecycle, including state changes, escalation, notification attempts, and responder actions. |
Repeated and out-of-order events#
A stable integration idempotency key prevents transport retries from creating a second raw event. Fingerprinting separately identifies repeated observations of the same condition. These are different layers of duplicate protection.
Source timestamps determine precedence; equal-timestamp recovery wins over firing. A persisted receipt timestamp is used when the source omits time information. Preserve stable identity fields and consistent timestamps across firing and recovery events.
Reading processing status#
- Accepted: the raw payload and outbox record are committed, but processing may still be pending.
- Processed: normalization and incident handling completed for that raw event.
- Quarantined: processing could not safely complete; inspect Delivery Health and the source payload.
- Recovery: the source reports the condition is no longer firing; verify its identity and timestamps match the intended lifecycle.
Protect the event history#
Do not delete raw events or rewrite database state to fix a live incident. Diagnose the source/parser/configuration issue and use the audited retry path where appropriate. Changes to integration identity fields with existing history may require a new integration. See Routing & deduplication.