Exchange Online outage: what to record and what to do

Status: Recovery reported by Microsoft. We will update this brief when Microsoft publishes its post-incident report.

What Microsoft has said

Microsoft tracked the outage in Service health in the Microsoft 365 admin center as two incidents:

• EX1550543: Exchange Online.
• MO1550821: Microsoft 365 services that depend on Exchange Online.

On its official @MSFT365Status account, Microsoft first reported "encouraging recovery progress, with service availability and email delivery performance improving across a growing portion of affected infrastructure". It later said it was "deeply sorry for the disruption this incident has caused our customers and partners" and was "seeing broad recovery and stability across our services".

The incident IDs and the latest updates for your own tenant are in the Microsoft 365 admin center under Health > Service health. If you can't reach the admin center, Microsoft posts public updates on its status page and the @MSFT365Status account.

What to do now

1. Record the incident IDs and your own impact. Note EX1550543 and MO1550821, the hours your users were affected, how many users and which locations. You need these for any service credit claim.
2. Don't ask people to resend mail. Mail servers queue a message and keep retrying when the receiving side is unavailable. The SMTP standard recommends retrying for at least four to five days before giving up, so most mail sent during the outage arrives late rather than being lost.
3. Check whether you are owed a service credit. Service credits are not applied automatically: you have to detect the outage, document it and submit a claim within the deadline. Microsoft's Service Level Agreement for Online Services sets the uptime targets and the claim process. If you buy through a Cloud Solution Provider (CSP) partner, the partner submits the claim, and for services other than Azure it must do so within one month from the end of the billing month in which the incident happened.
4. Read the post-incident report when it arrives. Microsoft publishes it in Service health for the incident. Check whether anything in it changes how you run mail flow or monitoring.

If you have a migration cutover coming up

An outage at the vendor's end is a reason to delay a cutover, not push through it. Moving mailboxes, switching MX records or retiring an old mail system while Exchange Online is degraded makes it hard to tell a migration fault from a service fault.

• Add "vendor service health is clear" as a go / no-go criterion for every cutover. Our go / no-go checklist template has a place for it.
• Check Service health on the morning of the cutover, and again just before you change DNS.
• Keep the old system's mail flow working until the new one has been stable for a few days. Our DNS and email cutover guide covers lowering TTLs and rolling back MX records.
• Plan the window with the cutover planner, and build a rollback step into the cutover runsheet.