# Before a monitoring tool change: alert history | SourceX

Canonical: https://refer.sourcex.si/guides/workflow-alert-deduplication-decisions
Last updated: 2026-11-04

Before a monitoring tool is replaced, inventory four things: the grouping and suppression rules in force over time, the alert groups each rule produced, the analyst notes that merged or split those groups, and the final incidents they fed. Record for each where it lives, how many years it covers, who owns it and when access ends. That history explains how an operations center told one outage apart from unrelated noise, and it is the part migrations often leave behind.

Observability consultants are often hired for exactly that migration. This guide covers what to notice during it and how to turn a conversation into a qualified introduction, without touching the data yourself.

## What should be inventoried before a monitoring tool replacement affects alert deduplication decisions history?

Inventory record classes, time coverage, system owners and the real access deadline: usually the date the old tool's contract or server is switched off. Incidents tend to survive a migration because the incident tracker stays; the reasoning that linked alerts to incidents often does not.

The reason is structural. Tools such as Prometheus Alertmanager deduplicate, group and route alerts, and can inhibit notifications for some alerts while others are already firing. PagerDuty attaches events to an open alert when they share a dedup_key. Those rules and keys live in the monitoring layer's configuration and history, not in the incident record. Replace the monitoring layer and the incident still says "storage outage", while the evidence of which alerts were judged to be the same outage may sit only in the retired system.

| Record class | Typical home | Coverage to note | Owner | Access deadline to ask about |
|---|---|---|---|---|
| Grouping, inhibition and routing rules | Alerting configuration, often in version control | Every rule version and when it changed | Platform or SRE team | Repository archiving, old server shutdown |
| Alert groups | Monitoring platform or event router | Group membership and timestamps per alert | Operations center | Tool's own history retention, contract end |
| Analyst notes | Incident tracker notes, chat channels | Share of merges and splits with a written reason | Operations center | Chat retention policy |
| Final incidents | Incident tracker | Severity, timeline, resolution, follow-up actions | Incident management lead | Usually long-lived |
| Post-incident reviews | Wiki or document store | One per major incident | Engineering leadership | Document retention schedule |

Do not recommend keeping data the company has no authority or policy basis to keep. Ask what exists and when it expires, then let the owner decide. The [Day 1 readiness guide](/guides/day-1-readiness-m) and the [QuickBooks to NetSuite migration guide](/guides/quickbooks-to-netsuite-migration-historical-data) describe the same "decide before you switch off" logic for acquisitions and finance systems. For a live tool retirement, see the [Opsgenie end-of-life guide](/guides/opsgenie-end-of-life-migration), and for what one incident platform holds, [PagerDuty incident exports](/systems/pagerduty-export-incidents).

## Why does the reasoning disappear when the incidents survive?

Because the decision was made in one system and recorded in another. An incident tracker stores the outcome. The monitoring layer stores the rule that grouped the alerts and the group membership itself. The analyst's reason for merging or splitting often sits in a chat channel with its own retention policy.

Grouping behavior also changes over time, which is why the rule history matters as much as today's rules. PagerDuty's Intelligent Alert Grouping, for example, compares alerts' Summary field for textual similarity by default, and its documentation warns that larger time windows raise the risk of overgrouping. A team that widened or narrowed that window two years ago produced different groups before and after the change. Without the setting history, the old groups can no longer be explained. PagerDuty's Events API adds another detail: a trigger event without a dedup_key always creates a new alert, and the same key sent through two different integrations on one service is not merged. Which integrations sent which keys is configuration that rarely makes it into a migration plan.

## An illustrative inventory sheet

Illustrative only; the company and figures are fictional. A 400-person logistics software company is replacing its monitoring and alerting stack. Its operations center director fills in the sheet from memory and the migration plan in one meeting, without exporting anything.

| Record class | System | Years held | Owner | Survives the replacement? | Reachable until |
|---|---|---|---|---|---|
| Grouping and inhibition rules | Alerting configuration in version control | 2019 to now | Platform team lead | Yes, if the repository is kept | Repository archiving decision |
| Alert groups and membership | Legacy monitoring platform | 2020 to now | Operations center director | No | Old platform contract end |
| Analyst merge and split notes | Incident tracker notes and chat | 2020 to now, chat from 2022 | Operations center director | Tracker notes yes, chat depends on policy | Chat retention policy |
| Final incidents | Incident tracker | 2018 to now | Incident management lead | Yes | Long-lived |
| Post-incident reviews | Wiki | 2019 to now | VP engineering | Yes | Document retention schedule |

Reading the sheet: the layer most at risk is alert group membership, tied to the old platform's contract end, followed by chat notes. The export question to test before switch-off is whether incident log entries can be pulled with their linked alerts. PagerDuty's REST API, for instance, returns the log entries for one incident with date-range filters, and notes have a separate list operation; whether a given company's tooling keeps the link back to alert groups is something only its own test can show.

## Ask the operations center director about coverage and rights

The operations center director usually knows coverage: which layers exist, how far back and in which tools. Rights and authority sit higher. Alert payloads and incident notes can contain customer identifiers, hostnames and production details, so the company's counsel and security lead decide what could ever be licensed and what would need removing first. The person who can authorize a licensing discussion is the CEO; the CTO or CFO often sponsors the conversation internally.

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.

Keep discovery at metadata level: what, how much, how long, which system, who owns it. Never collect alert exports, dashboards, credentials or incident documents. What stays unknown until SourceX reviews the opportunity: buyer interest in operations-center decision records, the rights review result for production and customer-related content, the de-identification required, and any price. Partners sign the Channel Partner Agreement before submitting introductions. Finding clients with this kind of history is covered in the [incident and on-call records field guide](/guides/a-partner-field-guide-to-finding-companies-with-incident-and-on-call-records), related record types on [decision records](/data-types/decision-records) and [ITSM ticket history](/data-types/itsm-ticket-history), and other sectors on the [industries hub](/industries).

## Go deeper on alert deduplication decisions

- [Alert deduplication decisions exception examples](/guides/alert-deduplication-decisions-exception-examples): a worked alert storm, from the first alerts to the analyst's merge decision.
- [Alert deduplication decisions records across systems](/guides/alert-deduplication-decisions-records-across-systems): a map of the keys that join monitoring, paging, chat and incident records.
- [Who can license alert deduplication decisions records](/questions/who-can-license-alert-deduplication-decisions-records): a short answer on which executive to introduce.
- [Alert deduplication decisions referral brief template](/resources/alert-deduplication-decisions-referral-brief-template): a fill-in brief for writing the company 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 operations center can show who merged its alert storms and why, before the old tool goes dark, [register as a partner](/register), check the company against [who qualifies](/who-qualifies), and read the [program terms](/terms) before you make the introduction.

## Sources

- https://refer.sourcex.si/terms
- https://prometheus.io/docs/alerting/latest/alertmanager/
- https://developer.pagerduty.com/docs/events-api-v2/trigger-events/index.html
- https://support.pagerduty.com/main/docs/intelligent-alert-grouping
- https://developer.pagerduty.com/api-reference/b3A6Mjc0ODE0Nw-list-log-entries-for-an-incident