Can alert groups be connected to human actions and final incident closure?
Often yes, but only while the retiring tool and its neighbors still share keys. An alert group lives in the alerting tool; acknowledgments and responder notes sit on the incident; the fix may be a change ticket elsewhere; the postmortem is often a wiki page. The trail holds together through identifiers copied between systems. A retirement that exports alerts but drops the incident numbers in tickets breaks it.
Two vendor facts show why the grouping layer is worth asking about. PagerDuty documents that related alerts can be grouped into one incident, and that responders manually merging incidents or moving alerts helps the grouping learn. Those manual corrections are human judgment recorded in the tool. Google's SRE book defines a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root causes and the follow-up actions. Put together, a well-kept history runs from machine signal to human decision to written conclusion.
PagerDutyRetirement events are real and dated. Atlassian stopped selling Opsgenie on June 4, 2025 and its licensing page gives April 5, 2027 as the date access ends. That does not mean every Opsgenie customer is at risk: many will migrate inside Atlassian's own products. It means consultants running these moves are already asking what history comes across; the Opsgenie end-of-life migration guide covers that specific move.
AtlassianThe alert-to-closure join map (evidence asset)
Illustrative. A 180-person logistics software company is retiring its alerting tool. Its SRE lead answers one question per stage: what key joins this stage to the next, and will the export keep it? The consultant writes down the answers only.
| Stage | Where it lives | Key that joins it to the next stage | Kept in the export? |
|---|---|---|---|
| Alert group | Retiring alerting tool | Incident ID assigned on grouping | Yes |
| Acknowledgment and reassignment | Retiring alerting tool, incident log | Incident ID and responder role | Yes |
| Responder actions and notes | Incident timeline, chat channel | Incident ID pasted in channel name | Partly: chat export not planned |
| Fix or rollback | Change ticket in the service desk | Incident ID in a ticket field | Yes, field is mandatory since 2021 |
| Postmortem and action items | Engineering wiki | Incident ID in page title | Yes, but action items tracked in a separate board |
Reading the map: the trail is joinable for incidents since 2021, with one gap (chat notes) the client can decide about before cutover. That is enough to describe the record set to an owner. Whether it has licensing value is for SourceX to assess.
Why alert-to-action trails get overlooked
Retirement projects are scoped as feature parity: routing rules, schedules, integrations. History is treated as an archive checkbox. The human layer, the merges, the reassignments, the notes, is exactly what a parity checklist skips. The PagerDuty incident export page shows what incident timelines typically hold, and the incident and on-call field guide covers which companies keep them. The tool-use training data page explains why multi-step operator records are a distinct data type.
Four metadata questions after the opener
When the SRE lead or platform owner confirms that alert groups can be traced, four follow-ups size the record set without anyone opening an incident:
- How far back does joinable history go? The year the incident ID became a mandatory field is usually the real start date, not the year the tool was bought.
- How many incidents, roughly, and how many reached a postmortem? A range is enough, such as a few thousand incidents with a few hundred written reviews.
- What does the retirement plan export, and what does it leave behind? Chat channels, merge history and reassignment logs are the usual gaps.
- Who owns the records and can approve a licensing discussion? For most software companies that is the CTO or VP of engineering, with legal sign-off on customer data inside alert payloads.
Does the company qualify, and what stays unknown?
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.
| Item | What you can know | What stays unknown until SourceX reviews it |
|---|---|---|
| Records | Systems, years, incident volume range | Whether buyers want this record set |
| Ownership | Who the client says owns the records | The rights review outcome |
| Authority | Who can approve a licensing discussion | Scope, price and terms |
| Reward | The published formula on /terms | Whether any reward becomes payable |
Sign the Channel Partner Agreement before submitting. The first valid introduction within the 90-day window is credited when the company submits a verified application, one partner per company. Use the incident records checklist before you submit, the network opportunity finder to list other clients facing a retirement, /rewards for payment mechanics, and the partner hub for other roles.
Reward disclosure and owner permission
Tell the owner, before any introduction, that you may receive a referral reward and that SourceX pays it separately, so it never reduces what the company is paid. The default reward on a company's first qualifying transaction is the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap. Illustrative arithmetic only: if the company were paid USD 200,000 for a qualifying completed handoff, the reward would be USD 60,000; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details. Then keep the introduction short: the retirement date, the joinable years and incident range the owner described, and a one-line description of SourceX licensing approved operating records directly from companies. Send it only once the decision-maker has agreed.
Go deeper on monitoring tool retirements
- Monitoring tool retirement meeting agenda: a timed agenda for the first conversation with the platform owner about alert history.
- Monitoring tool retirement archive context checklist: a checklist of export, retention and ownership facts to confirm before cutover.
- Monitoring tool retirement introduction email: an email template for introducing the decision-maker, with the disclosure sentence included.
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 the join map shows a traceable trail and the owner opted in, register as a partner, check the company against who qualifies, and review the program terms before sending the introduction.