Check Where Your Alerts Land Before the Next Outage: If Your Monitoring, Paging and Incident Bridge Run Through the Provider That Went Down, Silence Looks Like Health
Here is the 15-minute job for today. List every way an alert reaches a person in your shop. Next to each one, write down which provider it has to pass through to get to that person. Then circle every path that runs through the same provider as something it's supposed to be watching. If your monitoring alerts, your backup reports, your security notices and your incident chat all arrive through the Microsoft 365 tenant that spent Thursday and Friday struggling, your monitoring didn't break this week. It turned out to be the same system as your email. That's the existential moment a lot of IT people are having today, and the honest question that comes out of it is simple: what would I see if the thing that tells me were broken?
What happened, briefly
Microsoft 365 incident MO1550821, "Users may be unable to connect to multiple Microsoft 365 services," started at 18:26 UTC on Thursday, November 12. In Microsoft's statements, as quoted by the press, the load came from "servers being unexpectedly unavailable; straining the remaining infrastructure," and "a core process on the affected servers is becoming overwhelmed." Microsoft also said it had "no evidence of malicious activity." According to BleepingComputer, recovery was gradual and still not complete on Friday morning. Microsoft hasn't published its post-incident report yet, so the root cause is still open. We went through what is and isn't known, and why there's no evidence tying it to Patch Tuesday, in Did Patch Tuesday Break Microsoft 365?
This post isn't about Microsoft. Every provider has days like this, including the one you'd switch to. The lesson is about how your alerting is built, and it applies to Google Workspace, Slack, your ISP, your hosting provider and anything else you lean on for everything.
Why a quiet inbox lied to you
Monitoring tools report problems. They almost never report that they've stopped being able to report problems. So when the delivery path fails, the result looks exactly like a good day: no alerts.
Walk through what a typical small shop routes through one tenant. Uptime monitor alerts go to an email distribution list. The backup software emails a nightly job report. Antivirus or endpoint detection sends notices to the admin mailbox. Certificate expiry warnings go to the same mailbox. On-call is "whoever sees the email first." The incident bridge is a Teams or Slack channel. The status page you'd post to is behind a sign-in that uses the same identity provider. And the contact list you'd use to call people is in that provider's address book.
If that provider is down, every one of those goes dark at the same moment. The worst part is that it fails silently. Nobody gets a message saying "you're not getting your messages." If your alerts land in the mailbox that's down, the morning after an outage can look calmer than an ordinary Tuesday.
There's a second layer. Even the warning about the outage can share its fate. Microsoft's own documentation says you can sign up for Microsoft 365 service health email notifications and name up to two email addresses. If both of those addresses live in the tenant that's having the incident, the notice about the outage gets delivered into the outage.
The 15-minute self-check
Get a sheet of paper or a blank spreadsheet. Make three columns: the alert, what it depends on to reach a human, and what it watches. Then go down this list:
Monitoring alerts. Server, network and application alerts. Where do they go: email, chat, text?
Uptime checks. Who checks that your website, VPN and mail are reachable from outside, and where does that tool send its warning?
Security alerts. Endpoint detection, antivirus, firewall and sign-in risk alerts. Many of these default to an admin mailbox.
Backup job reports. A failed backup you never hear about is the expensive kind. Where does the failure notice go?
Certificate and domain expiry. These warnings often go to one person's mailbox, sometimes someone who left years ago.
On-call paging. If something pages a person, how does the page get there? An app, SMS or email?
The incident bridge. Where would your team meet to fix things? If the answer is a chat channel on the provider that's down, you have no room to meet in.
The status page. Where would you tell customers or staff what's going on, and can you sign in to it without the provider that's down?
For each row, write down the vendor or tenant that the message has to pass through to reach a person. Then circle any row where that vendor is the same one the alert is meant to watch, or the same one that carries your daily mail, chat and sign-in. Every circle is a place where an outage and the alert about it fail together.
Most shops find at least one circle, and that doesn't mean anyone did a bad job. It's what happens when you take every tool's default settings, and the default is almost always email.
Fixes, cheapest first
1. Add one out-of-band channel for the alerts that matter most. It doesn't have to cover everything. Pick the handful of alerts you'd want at 2 AM, like site down, backup failed or ransomware detected, and send a copy somewhere that doesn't depend on your main provider. Most monitoring tools can send a text message or a mobile push notification in addition to email. Some can call a webhook, a web address that a different service listens on, so the message can land with a notifier hosted by another company. One concrete example from documentation we checked today: Azure Monitor action groups support email, SMS, push notifications to the Azure mobile app, and voice calls, plus automated actions such as webhooks. Microsoft's documentation also says that where SMS or voice isn't supported in your country, you can point the action group at a webhook to a third-party SMS or voice provider instead. Whatever tool you use, the test is the same. Ask whether the message would still arrive if your mail and chat were both down.
2. Run one uptime check from outside your own cloud, and have it notify outside your own mail. A check that runs inside the same provider it's checking can go down along with it. Use a check hosted somewhere else, aim it at the things your people and customers actually touch, and send its alert by text or push to a phone.
3. Build a dead-man's switch, so silence becomes a signal. This is the fix that answers the question in the headline. Set up a scheduled job that sends an "all good" ping on a regular schedule, say once an hour or once a night after backups finish. Then have a separate service, ideally run by a different provider, alert you when the ping doesn't arrive on time. Many uptime and cron-monitoring services offer this, usually called a heartbeat check. The normal arrangement is that bad news has to travel to you. A heartbeat flips it: good news has to keep arriving, and when it stops, you find out. A broken delivery path stops looking like a quiet night.
4. Keep an out-of-band contact list and a backup bridge. Print the phone numbers of the people you'd call during an incident, or keep them somewhere you can reach without signing in to your main provider. Agree ahead of time where you'll meet if your chat is down. A phone bridge, a group text, or a channel on a different provider all work. Write it on the same sheet. A plan nobody can find during the outage doesn't help.
5. Know where your provider's status lives without signing in to the affected tenant. For Microsoft 365, Microsoft's documentation says that if you can't sign in to the admin center, you can check the public service status page at status.cloud.microsoft, and it points to the @MSFT365Status account on X for information on certain events. The same page says the Microsoft 365 Admin mobile app can show service health with push notifications. Also make sure the email addresses you give for service health notices aren't both inside the tenant you're watching. Other providers have their own public status pages and feeds. Bookmark yours now, on a phone, before you need it.
Accepting the risk is allowed, if you do it on purpose
Not every shop needs a second notifier. A five-person office with no on-call rotation might reasonably decide that during a provider outage, nobody is getting paged anyway. That's a legitimate decision. What makes it a decision rather than an accident is writing it down, along with what you'll do instead.
One sentence is enough: "We looked at our alert paths and accepted that they share fate with our mail provider. During a provider outage, we'll check backups, the firewall and the website directly instead of trusting a quiet inbox." Put the date on it and tape it next to your contact list.
That last part is the habit worth building. During a provider incident, assume your alerts are not reaching you. Open the backup console and look at last night's job. Load your website from your phone on cellular data. Check the firewall's own dashboard. Look at the systems themselves, not at the absence of complaints about them.
"We looked and accepted it" is a perfectly good result. Most shops never looked, and found out this week.
If you only have an hour
Do the eight-row self-check above and circle the shared-fate paths.
Send your two or three most important alerts to a phone by text or push, in addition to email.
Set up one heartbeat for the job you'd hate most to fail silently, usually backups.
Write down the out-of-band contact list, where you'll meet if chat is down, and the public status page for each provider you depend on.
For everything you didn't fix, write one sentence accepting it, and what you'll check by hand during the next outage.
Sources: Microsoft 365 incident MO1550821 as quoted by BleepingComputer, The Register and SecurityWeek (no post-incident report yet); Microsoft Learn, "Create and manage action groups in Azure Monitor" (learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups); Microsoft Learn, "How to check Microsoft 365 service health" (learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health), both read November 13, 2026.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Comments