Laptop on an office desk showing an email icon with a stalled progress bar

Microsoft 365 Outage (EX1550543): What Microsoft Has Said

by

If your Outlook, Teams or SharePoint stopped working on Thursday, November 12, the problem is on Microsoft’s side, not yours. Microsoft confirmed a large Microsoft 365 outage on Thursday. Service restored, per Microsoft: at 11:15 PM on November 13 it marked both incidents service restored and gave a preliminary root cause (below). Its post-incident reports are still to come. There was a lot of guessing about the cause (an attack, a bad update, you name it), so here is what Microsoft has actually said, in order, with a source for every line. All times are Eastern. Current as of Microsoft’s final 11:15 PM update on November 13, 2026.

Updated 8:25 PM ET, November 12: added Microsoft’s 8:06 PM update. Updated 9:00 PM ET: added Microsoft’s 8:45 PM update. Updated 9:30 PM ET: added Microsoft’s 9:09 PM update. Updated 10:10 PM ET: added Microsoft’s 9:54 PM update, a setback. Updated 11:00 PM ET: added Microsoft’s 10:34 PM update, which says there is no indication of malicious activity. Updated 11:30 PM ET: added Microsoft’s 11:10 PM update. Updated 12:10 AM ET, November 13: added Microsoft’s 11:59 PM update. Updated 1:15 AM ET: added Microsoft’s 12:43 AM update. Updated 7:50 AM ET: added Microsoft’s overnight updates (1:16 AM through 7:00 AM), including recovery under way by region and a 48-hour email timeout window. Updated 8:25 AM ET: added Microsoft’s 8:00 AM update. Updated 9:25 AM ET: added Microsoft’s 9:01 AM update. Updated 10:10 AM ET: added Microsoft’s 9:57 AM update. Updated 11:10 AM ET: added Microsoft’s 10:53 AM update. Updated 1:10 PM ET: added Microsoft’s 12:57 PM update, its first explanation of the cause. Updated 3:25 PM ET: added Microsoft’s 3:02 PM update. Updated 5:15 PM ET: added Microsoft’s 5:00 PM update. Updated 9:25 PM ET: added Microsoft’s 9:13 PM update. Updated 11:40 PM ET: added Microsoft’s final 11:15 PM update; Microsoft marked both incidents service restored and gave an official start time of 5:05 AM on November 12, earlier than the 11:17 AM first update this post used as the start.

The short version for your business

  • Nothing is wrong with your computers, your network or your accounts. Don’t reset passwords, remove and re-add mail accounts, rebuild Outlook profiles or reinstall Office. None of that fixes this, and it makes extra work once Microsoft recovers.
  • Not an attack. At 12:57 PM on November 13 Microsoft said: “This was a technical issue not related to cyber or AI / agents.” Microsoft says “The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change.” Microsoft calls that its preliminary root cause. It says a preliminary post-incident report will follow within two business days and a final one within five.
  • Microsoft says email delivery “may be delayed,” and it has extended the email timeout window to 48 hours “to help protect delayed messages.” It has not said mail is rejected or lost (details below).
  • Not everything is down. Microsoft says parts of its services that don’t depend on Exchange “remain functional”: Teams chat and online meetings “remain largely functional,” and “accessing files stored directly in SharePoint Online remains functional.” Teams calendar and meeting scheduling may fail.
  • Be careful with links: Microsoft says Safe Links “may be unable to verify URLs,” which can affect clicking links in Outlook and Teams.
  • If your phones run on 3CX, calls do not go through Exchange. Features tied to Teams or Microsoft 365 may be affected while those services are down.
  • Still having trouble? Call us at (270) 360-1258 instead of emailing.

What’s affected

  • EX1550543, Exchange Online, first public update 11:17 AM (Microsoft’s final update gives an official start of 5:05 AM): mailbox access through Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (phones) and REST.
  • MO1550821, opened 1:26 PM and also posted on Microsoft’s public status page: Teams, SharePoint Online, Copilot, Defender XDR, Planner, To Do, Intune, Defender for Office 365, several Purview services (DLP, auto labelling, communication compliance, data classification), Power BI export of sensitivity-labelled reports to PDF, the Microsoft 365 Apps admin center (Cloud Update, Cloud Policy, Inventory), Universal Print, Windows 365 (Cloud PCs that use Purview Customer Key), some Microsoft 365 admin center pages, Microsoft Graph requests for mail, calendar and contacts, recently used files in Microsoft 365 apps, and Microsoft 365 Education features. The list has grown through the afternoon. At 7:00 PM Microsoft rewrote the scope: features “that interact with Exchange Online and email services are impacted,” while parts that don’t “remain functional.”
  • Downdetector logged more than 129,000 Outlook reports by 1:09 PM per Variety, and roughly 130,000 at peak per CNBC, Today and Newsweek.

Timeline, from Microsoft’s posts

The Microsoft 365 admin center needs a login, so the quotes below come from the full Service Health text, which the University of Pennsylvania mirrors publicly (find EX1550543 and click Details to expand the update history). Each time is when that admin center entry was posted. Where a time links to an @MSFT365Status post, the X post is a shortened version of the same update and usually went out a few minutes later. TechRadar’s live blog reproduced several of the full entries.

  • 11:20 AM: First admin center entry. Investigating. Microsoft’s first X post followed at 12:54 PM, per Variety.
  • 12:45 PM: “connectivity errors occurring on a portion of Exchange Online infrastructure which receives and processes users’ access requests.”
  • 1:19 PM: The affected infrastructure “is experiencing elevated load across multiple regions.” Microsoft is restarting and repairing it. This update reached X at 1:35 PM, per Variety.
  • 1:29 PM: Some US traffic is moved off the affected infrastructure. Other services are split out to MO1550821 (BleepingComputer).
  • 1:43 PM: Servers are “becoming intermittently unavailable, which places additional strain on the remaining infrastructure.” Outlook traffic is spread across worldwide infrastructure (Variety quotes the X version). Microsoft is still looking for “the source of the increased traffic” (Deadline quotes the earlier “unexpected increase in a specific type of service traffic” line).
  • 2:06 PM: “we’ve paused all deployments and configuration changes while we review recent changes for any correlation to this event.”
  • 2:18 PM: The key update: “the elevated load isn’t driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure.”
  • 2:43 PM: Servers are “failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks.”
  • 2:57 PM: Walked back 14 minutes later: “we haven’t identified any recent changes that correlate with the start of impact.” The failed checks “may originate from a specific component on the affected servers that’s responsible for processing them.” Microsoft bypasses that component on a subset of servers, stops more servers from being pulled out of service, and starts looking at “elevated processor usage.”
  • 3:38 PM: “many of the affected servers have become unresponsive, which is preventing us from confirming whether the change is effective.” Microsoft restarts them with the change in place.
  • 3:56 PM: First progress: “an alternative health check method” lets a subset of servers “successfully return to service.” Microsoft rolls it out more broadly, plus an automated process to keep restarting servers that hang. The change question is back: “a small number of configuration updates that we’re investigating as potential contributors.”
  • 4:31 PM: Still restarting and validating servers, and “assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery.”
  • 5:00 PM: A setback: “our actions taken thus far have not provided the anticipated relief.” Also: “a core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss.” The new plan is to fully isolate a portion of the infrastructure, restart it, and gradually reintroduce traffic before doing the same more broadly. Microsoft is also “evaluating whether isolating traffic within each region may allow affected regions to recover independently.”
  • 5:57 PM: The first good news: “We’ve begun returning a portion of the affected servers to service, and they’re remaining stable so far.” Microsoft reports “limited recovery in some regions” and is adding “protective traffic management measures in a specific location to reduce load on the affected infrastructure,” to be expanded if they help. Users “may experience a gradual recovery as their clients reconnect to the service.”
  • 6:59 PM: The returned servers “initially remain healthy,” but “they can become unresponsive again once they begin receiving traffic.” Microsoft is analyzing diagnostic data “to determine what’s triggering this behavior,” is “temporarily limiting which types of traffic can reach the affected infrastructure in specific locations” to see whether a particular type of request is contributing, and is “rebuilding a subset of affected servers using a previous software configuration” to test whether that keeps them up.
  • 8:06 PM: Microsoft says “a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests.” It is validating a configuration change on a subset of servers before applying it more broadly with restarts. In parallel: “we’ve begun reverting a recent network configuration change that correlates with the start of impact and are monitoring to determine whether this contributes to recovery.” The temporary traffic limits are now in effect in specific locations, and Microsoft will “gradually reintroduce additional traffic” if servers there stay stable.
  • 8:45 PM: “We’re seeing positive results with our efforts to restart affected infrastructure.” Microsoft is monitoring those servers “to verify stability,” and “remediation actions will be expanded as we confirm stability with the changes applied.” The incident is still open.
  • 9:09 PM: “We’re applying infrastructure capacity improvements where possible in an effort to help support traffic in regions coming online.” Microsoft is monitoring the changes to “identify strategic actions that can help to improve service health across all affected regions.” Still open.
  • 9:54 PM: Another setback: “We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected.” Microsoft is “identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.” Still open.
  • 10:34 PM: Microsoft is reviewing traffic flows and affected infrastructure “to identify opportunities to optimize routing” and verifying why services failed. For the first time it addresses an attack directly: “we can confirm that there is no indication this is the result of malicious activity.” Still open.
  • 11:10 PM: Microsoft is working on server stability: “This includes adjusting traffic protocols, redistributing traffic, and applying strategic traffic blocking measures.” It reports “partial recovery across regions” where these changes are in place, “however, these actions aren’t resulting in sustained recovery,” so it is reviewing what else it can do. Still open.
  • 11:59 PM: As mitigations were applied, “we’ve observed a surge in outbound call volume from our routing services to our backend servers.” Microsoft links the heightened volume to the traffic rebalancing it has done during the event and says: “We’re working on multiple workstreams to pinpoint the underlying cause of this traffic influx and address it.” It is “scaling up virtual machines to increase capacity and reduce load” and trying to force-sync its recent network change to machines in a bad state, but “we are encountering issues with the machines being stuck in a bad state, preventing our changes from syncing as expected.” Still open.
  • 12:43 AM, November 13: “We’re continuing to pursue multiple workstreams to pinpoint the underlying cause of the traffic influx and advance the recoverability of the backend servers.” Microsoft repeats: “As of now, we are not aware of any malicious activity that is causing this incident.” It promises a Post-Incident Report: “Once mitigated, we will provide full details of the root cause, defense-in-depth repair items, and more within a Post-Incident Report.” Still open, and no root cause posted yet.
  • 1:16 AM: Microsoft is evaluating traffic controls “such as traffic throttling, protocol adjustments, and failover routing” to improve stability.
  • 1:56 AM: After patches and reboots: “At this point, we have observed marginal success.” Microsoft is adding capacity with virtual machines.
  • 2:25 AM: The first lasting progress: “We’re seeing positive results for server stability after applying an upstream authentication/routing configuration component patch to a portion of our infrastructure.”
  • 3:06 AM: With the patch holding where applied, Microsoft starts expanding it “to focus on infrastructure supporting regions currently within or entering peak business hours.”
  • 4:55 AM: “We are seeing early signs of stabilization, but service capacity has not yet returned to normal levels.” For mail: “we are extending the email timeout window to 48 hours to help protect delayed messages while service recovery continues.”
  • 6:01 AM: “recovery actions completed across portions of the affected infrastructure in the Asia Pacific region,” with improvements in mailbox access and delayed email processing. “However, some users may continue to experience intermittent issues.”
  • 7:00 AM: “We’re seeing encouraging recovery progress in Europe, with service availability and email delivery performance improving across a growing portion of affected Microsoft 365 infrastructure.” “Japan remains comparatively more stable, while North America is also improving; however, some users may still experience intermittent issues as recovery actions continue.” Microsoft says it has “no evidence of malicious activity associated with this incident” and repeats that a Post-Incident Report with the root cause will follow. Still open.
  • 8:00 AM: “We’re seeing continued recovery progress across affected regions, with broader improvements now observed in North America and sustained improvements across much of Europe.” Microsoft also sees “encouraging recovery signals in Asia Pacific,” “although some users may continue to experience intermittent access issues or delayed email delivery as mitigation progresses across the remaining affected infrastructure.” New in the incident details: “on-prem mail flow may be affected if it goes to or from Exchange Online.” Still open.
  • 9:01 AM: “We’re continuing to see improvements in service availability, with email queues significantly reduced and approaching normal levels.” “Some users may still experience intermittent access issues or delayed email delivery as recovery continues.” Microsoft is “restoring the remaining affected infrastructure while investigating residual service issues.” Still open.
  • 9:57 AM: “We’re observing sustained improvements in service availability as recovery progresses across affected Microsoft 365 services.” Still, “some users may still experience intermittent connectivity issues or delayed email delivery.” “Our efforts are increasingly focused on resolving the remaining issues and restoring consistent service for all affected users.” Still open.
  • 10:53 AM: “We remain focused on addressing residual impact and ensuring reliable service restoration.” Microsoft is checking recovery across connection methods and monitoring for sustained stability. Still open; updates are now about every two hours.
  • 12:57 PM: Microsoft apologizes (“We are deeply sorry for the disruption this incident has caused you and your business.”) and reports: “We are seeing broad recovery and stability across our services.” On the cause, for the first time: “This was a technical issue not related to cyber or AI / agents.” “The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change.” “We have addressed the underlying issue and continue to restore service to remaining customers and regions.” “We will provide a full post-incident report once our review is complete.” Both incidents are still listed as service degradation, not resolved, and the formal root cause field still reads N/A.
  • 3:02 PM: “As infrastructure stabilizes, we’re still draining queued messages and rebalancing traffic, so customers may see improved sign-in/access while delivery and processing continue to catch up.” “We do not have an ETA for full recovery yet.” “Service access can recover before mail flow fully normalizes.” Still open.
  • 5:00 PM: “We continue to observe sustained service recovery across the previously affected environments.” “Due to the severity of impact this incident caused, we’re monitoring for an extended period to ensure no additional mitigative actions are required.” In parallel, “we’re monitoring the backlog of email messages accrued during this event to ensure all process successfully before considering the issue resolved.” Still open: Microsoft has not declared it resolved, and the post-incident report is still to come.
  • 9:13 PM: “We’ve confirmed continued recovery across previously affected environments.” Microsoft says it will keep monitoring “to ensure the mitigation actions taken remain effective” and will track processing of the email backlog. It is still working on remaining problems in related Microsoft 365 products: “We believe the majority of these scenarios have been addressed, with work continuing on any remaining scenarios.” Still open: Microsoft has not declared it resolved, and the post-incident report is still to come.
  • 11:15 PM: Final update. Microsoft marked EX1550543 service restored, and MO1550821 followed at 11:17 PM. “This was a technical issue not related to cyber or AI / agents.” Its preliminary root cause: “The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change.” It adds: “We have addressed the underlying issue and continue to restore service to remaining customers and regions.” and “Given the scale of demand, we restored services gradually, validating stability at each stage. While this took longer, it helped ensure a stable restoration.” Microsoft gives an official start of 5:05 AM on November 12 and an end of 11:10 AM on November 13. That start is about six hours before Microsoft’s first public update at 11:17 AM. “We’ll provide a preliminary Post-Incident Report within two business days and a final Post-Incident Report within five business days.”

In its final update Microsoft filled in a preliminary root cause: “The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change.” The final post-incident report is due within five business days.

Our read (ours, not Microsoft’s)

Servers started failing automated health checks and were pulled from rotation. The remaining servers took the extra load, and many of them stopped responding too. That pattern is a capacity cascade. Microsoft has described the mechanism but has not named a trigger: a recent change was suspected at 2:43, not found at 2:57, and back on the table by 3:56. The first fix helped some servers and did not hold broadly; servers brought back at 5:57 PM were stable at first, but by 6:59 PM Microsoft reported they can stop responding again once traffic returns. Microsoft is now testing whether certain types of requests, or a previous software configuration, are involved; that is a line of investigation, not a finding. At 8:06 PM Microsoft said it is reverting a recent network configuration change that “correlates with the start of impact.” Correlation is not a confirmed cause, and the root cause field read N/A until Microsoft’s final update.

At 12:57 PM on November 13 Microsoft gave its explanation: the incident “was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change,” and it was “not related to cyber or AI / agents.” Microsoft has not yet explained how that network issue led to the server failures described above, or why recovery took as long as it did. Microsoft says a preliminary post-incident report is due within two business days and a final one within five business days. Until those are out, treat anything more specific than Microsoft’s own sentence as guessing.

What it does and doesn’t look like

  • Not a traffic flood, per Microsoft’s own 2:18 PM update. At 10:34 PM Microsoft said there is “no indication this is the result of malicious activity,” and none of the coverage we have read (ABC, Global News, SecurityWeek) reports one. Microsoft’s statement to CNBC only says it is “investigating reports of users experiencing issues with Microsoft 365 services, primarily issues with Exchange Online.” CISA’s alerts page had nothing on it when we checked at 6 PM; its newest alert was dated November 10. That is an absence of evidence, not a ruling.
  • Not Google. The Google Workspace status dashboard showed no incidents on November 12, so Gmail showing up on Downdetector is most likely people reporting “my email is down.” Cloudflare’s status page shows nothing broad either, and AWS says it is “operating normally” and that outage reports about it are inaccurate, per CNBC.
  • Not DNS, in our own tests. The Outlook hostnames resolve to normal Microsoft front-end addresses on Cloudflare (1.1.1.1), Google (8.8.8.8) and our internet provider’s resolver.
  • Not routing, in our own tests. The front-end addresses answer ping with no loss, but most secure web connections (TCP 443) to them time out. The traffic is arriving; the servers aren’t taking the work. All afternoon it has flipped between zero and three of our four test addresses accepting connections.
  • Sign-in looks fine from here. Microsoft’s sign-in service (login.microsoftonline.com) answers normally. The Microsoft Graph API answers too, but mailbox requests come back with server errors (502, 503 and 504).

These DNS, ping, connection and Graph results are our own tests from one network, so weigh them accordingly.

If you manage IT and are fielding the calls

  • Nothing on the user’s side fixes this. Skip password resets, profile rebuilds and reinstalls.
  • Inbound mail: Microsoft’s 7:00 PM scope text for MO1550821 says “email delivery may be delayed.” At 4:55 AM on November 13 Microsoft said it is “extending the email timeout window to 48 hours to help protect delayed messages while service recovery continues.” It has not said anything about mail being rejected or lost. We have not tested it end to end. If outside senders are getting temporary (4xx) errors, their mail servers retry on their own schedule, typically for a day or more, so late is more likely than lost. Check message trace and your own mail queues once you can get in. If you run hybrid Exchange, Microsoft says “on-prem mail flow may be affected if it goes to or from Exchange Online.”
  • Service restored, per Microsoft: it marked EX1550543 and MO1550821 service restored at 11:15 PM and 11:17 PM on November 13. Its final note also says it continues “to restore service to remaining customers and regions,” so a few users may still see delayed mail. Check message trace for anything that went missing during the outage.

Tektel customers: if something still isn’t working now that Microsoft reports service restored, call us at (270) 360-1258 and we will sort out what is left on your side.

We will update this post when Microsoft publishes its post-incident reports.

Sources

Leave a Comment