Exchange Online had two separate problems on 9 November, one affecting outbound mail to Outlook.com, Hotmail.com and Live.com addresses, the other blocking Outlook on the web for users in Europe and later across EMEA. Both faults sat on Microsoft's side, not yours.
Started
07:29 UTC
Duration
Lasted 4h 28m
Source
IsDown
Next time
Microsoft 365 is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Exchange Online
What happened?
The first incident started at 05:07 UTC and involved some users being intermittently unable to send email to Outlook.com, Hotmail.com or Live.com addresses, with senders getting NDRs citing 550 5.7.1 or 550 5.7.23 SPF violations. Microsoft's only update, posted at 05:24 UTC, asked affected users to send fresh Network Message IDs, logs and .eml examples to support, and said the next update would come by 07:00 UTC on 11 November, a gap of more than a day. That incident remains open with no resolution filed. The second incident started separately at 07:29 UTC, affecting mailbox access via one or more Exchange Online connection methods. By 07:56 UTC Microsoft narrowed the scope to Outlook on the web and said impact was specific to some users in Europe. By 09:48 UTC the scope had widened to Europe, the Middle East and Africa, and Microsoft said affected requests were failing due to unexpected connection terminations within a section of Exchange Online infrastructure. They described checking network connectivity, infrastructure load, request routing and recent configuration changes, but gave no root cause. That second incident ran for 4h 28m before resolving. No user reports were filed in this window on our side. Only Exchange Online is listed as an affected component for the day. Microsoft's history shows 60 incidents in the last 90 days with a median duration of 9 hours 3 minutes, and 329 incidents in total at a rate of about 8 per month, so a day with two separate filings is not unusual for this service.
Learning
Both of these incidents were faults inside Microsoft's own infrastructure, one in mail routing logic that generates SPF-related NDRs, the other in connection handling for Outlook on the web, and neither is the kind of thing an external check against your own product would catch. If your monitoring only watches your own endpoints, it stays green through this because your endpoints are fine, the problem is on the path between Microsoft's servers and the recipient or browser session. That is why Microsoft's own status page, which logs what their engineers see internally, and an external check, which sees only what crosses the public internet, can both report accurately and still look like they disagree. The pattern here, a single vague update followed by a long wait for the next one, or a scope that grows from "some users in Europe" to "Europe, Middle East and Africa", is typical of how these filings evolve. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
