Alert deduplication system map: the keys that join alerts, incidents, notes and rule changes

This system map belongs to the alert deduplication decisions guide. The guide is about timing; this page is about wiring: where each record sits, which identifier points to the next one and what a fully joined case looks like when every pointer holds.

Where each record lives

A typical operations center spreads one decision across five places. The table is the map: system, the record it holds, the key that links it onward and the usual owner. Tool names are examples; a company's own stack may differ.

Ownership matters as much as the keys. Five owners means five retention policies and five people who decide what is kept when a tool is retired.

The five joins, one by one

1. Alert to group. In PagerDuty's Events API, trigger events that share a dedup_key join an open alert. A trigger without a key always opens a new alert, and the same key sent through two different integrations on one service is not merged. In Alertmanager, grouping works on labels. Either way, the key or label set is on the alert record. It is lost when only incidents are exported.

2. Group to incident. The incident ID is stored on the group, or the alert list is stored on the incident. Ask which side holds the link and check both. When incidents are merged in PagerDuty, the alerts move into the target incident, and the source incidents are resolved with the reason "Merged" and a reference to the target. That reference is itself a linking key, and it is the structured trace of a human decision.

3. Incident to analyst note. PagerDuty's REST API lists the log entries for one incident, with date filters, and lists notes through a separate operation. A complete join therefore needs both calls. Other trackers differ, so ask the operations center what its tools can export rather than assuming.

4. Incident to rule change. The change record or commit that altered grouping or inhibition should cite the incident. Alertmanager inhibition rules name source and target matchers and an equal list of labels that must match; a reviewer can only explain why those labels were chosen if the change points back to the incident. This join is often missing when a rule is edited directly in a console.

5. Chronology. Alert timestamps, incident timestamps and chat messages may come from three clocks and three time zones. A reviewer normalizes them to show that the merge happened before resolution, as a live judgment, not afterward as a tidy-up. The ITSM ticket history page covers how ticket timelines age.

One fully joined case (Illustrative)

Invented for this page. A fictional 600-person payments software company. Every identifier below is made up and shows the shape of the chain, not a real record.

Follow any row to the next and the case holds together. Remove step 6 and the commit becomes an unexplained edit. Remove the merge reference in step 4 and INC-8811 looks like a duplicate someone closed. Keys of this kind are what turn five exports into one account of a decision. The worked alert storm shows the same chain from the analyst's side.

Where joins break during a migration

• Only incidents are exported. Group membership and dedup keys stay in the retired platform.
• Integrations are rebuilt. New integrations can issue new keys, so old and new alerts for the same source no longer match.
• Chat retention runs out. The note in the tracker survives; the discussion that produced it may not.
• Rules move to a new syntax. Converted rules arrive without their commit history, so step 6 loses its origin.
• Clocks are not recorded. Exports without time zone information make chronology guesswork.

Audit trails in other tools face the same problem; audit logging for MCP integrations is one example. Related record patterns are on decision records.

Test the map with the operations center, at metadata level

Ask the operations center director, without exporting anything: which of the five systems exist, since when, who owns each, whether commits and change tickets cite incident IDs, and when the old monitoring platform goes dark. Never collect alerts, notes, dashboards or credentials.

The company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 70% of the data is in English. Customer contracts, hostnames in alert payloads and employee names in notes all affect what could be licensed; that stays unknown until SourceX reviews it. For roll-ups that inherit several monitoring stacks at once, see MSP roll-ups and private equity. The referral brief template turns your answers into an introduction.

Next step

Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's alerts, incidents and rule changes still carry the keys that join them, register as a partner, check the company against who qualifies and read the program terms before you make the introduction.