Note: I probably should have written about this topic sooner. SharePoint Alerts are being retired. You've probably seen the banner by now, it's been showing up in the classic "Alert me" dialog for months.
New alert creation has already been blocked since January 2026. Full retirement, which means every remaining alert stopping permanently, happens in July 2026. An inventory of existing alerts is easy enough to create, and it can help establish who created the alerts, allowing Admins to contact those people to identify whether the alerts are still relevant and need some replacement functionality.
Scanning for alerts isn't enough
Alerts are per-user, per-list, and completely invisible to anyone except the person who created them and the site owner. A tenant-wide list of "500 alerts exist" tells you almost nothing useful on its own. It doesn't tell you which of those 500 are a compliance team's daily digest versus someone's forgotten test from three years ago.
A few things make this messier than it first looks.
Users can check their alerts here: https://yourtenant.sharepoint.com/sites/yoursite/_layouts/15/mysubs.aspx
Alerts have already been quietly expiring since October 2025. Microsoft's own phased rollout means any alert nobody actively renewed in the last several months has already stopped working, silently, with no notification to anyone. If your scan comes back with far fewer alerts than you expected, that's not necessarily the script missing something. It might mean the retirement's own expiration mechanism already did some of the cleanup before you ever got around to checking. Worth knowing either way, since it changes how much urgency remains for what's left.
Alerts are scoped at the web level, not the site collection. A scan that only checks each site's root web will miss anything registered on a classic subsite underneath it. If your tenant still has subsite hierarchies rather than flat modern sites, that's a real gap, not a script bug, and worth explicitly accounting for rather than assuming a clean scan means a clean tenant.
The API doesn't tell you when it's blocking you. I tried adding a test alert via PnP PowerShell to confirm the retirement's behaviour firsthand. The UI is honest about it, a clear red banner and a disabled OK button. PowerShell was not. It failed with a generic error, "Item and item.ParentList cannot both be null," nothing about alerts, nothing about retirement. If you're scripting anything against alerts right now and hit that exact message, it isn't your code. It's the block, just not explaining itself.
A quick manual check first
Before running anything tenant-wide, it's worth confirming what a single site actually has registered. This is the snippet to run first, on one site, before anything else:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive -ClientId "<your-client-id>"
Get-PnPAlert -AllUsers | Select-Object Title, ID, EventType, Filter, AlertTime, StatusThat alone is often eye-opening. It shows you exactly what's registered, who it belongs to, and whether it's still active (Status: On) or already lapsed. Run this on two or three sites you know well before trusting a tenant-wide sweep to tell you anything.
The inventory, tenant-wide
The single-site check above doesn't scale past a handful of sites. For a full tenant sweep, two scripts are linked below:
- A list-setup script, which creates the destination SharePoint list with all the columns needed to capture scan results (who created each alert, which list it watches, how it's delivered, when it was scanned, and a status field for the review workflow that follows).
- The scan script itself, which loops every site in the tenant, temporarily elevates the running account to Site Collection Administrator just long enough to see other users' alerts on that site (regular SharePoint Admin rights don't grant this by default, it's a deliberate Microsoft boundary), scans, then removes that elevation immediately after, success or failure. It writes one item per site to the list, including sites with zero alerts, so the list itself proves which sites were actually checked rather than leaving gaps you'd have to assume were clean.
Both are available in the scripts library.
Once you have the list, don't act on it alone
This is the part that's easy to skip when you're racing a deadline. The inventory tells you an alert exists and who it's registered to. It does not tell you whether it still matters.
Before migrating or removing anything, contact the alert's owner first. Someone's "Issue tracker list: All items" alert might be an ignored leftover from a project that ended two years ago. It might also be the one thing standing between a compliance deadline and a missed one. The list can't tell the difference. Only the person who set it up can.
If you do decide an alert is safe to remove once you've had that conversation, it's a one-line command:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive -ClientId "<your-client-id>"
Remove-PnPAlert -Identity "<alert-id-from-your-inventory>"Do this one alert at a time, after confirmation, not as a bulk sweep. The July 2026 cutoff is going to remove these for you anyway. The only thing you control right now is whether the people who depend on them find out from you, calmly, in advance, or from a missing notification after the fact.
Need help inventorying and migrating SharePoint Alerts before the July 2026 cutoff?