Cloud & DevOpsNote
Microsoft’s own status posts from 17:54 UTC on 12 November to 8:30pm IST on 13 November: what failed, the 20 services hit, and what an administrator can do.
Microsoft 365 had been failing for 21 hours at 8:30pm IST on Friday 13 November, and Microsoft had not declared it fixed. The first post came at 17:54 UTC on Thursday, 11:24pm in India: users in the Americas could not reach their Exchange Online mailboxes, tracked as EX1550543.2 Thirteen minutes later Microsoft said users in any region could be affected.3 By Friday its incident MO1550821 listed 20 services, from Outlook and Teams to Copilot, Purview, Defender and Intune.1 At 14:00 UTC email queues were “significantly reduced and approaching normal levels”. In its latest update, at 14:56 UTC (8:26pm IST), Microsoft reported “sustained improvements in service availability”, still listed the incident as a service degradation, warned of intermittent connectivity and delayed mail for some users, and said it had “no evidence of malicious activity”. A post-incident report with the root cause will follow once mitigation is complete; the next update is due by 16:00 UTC.1
21h
from Microsoft's first post to 8:30pm IST, still not resolved
Microsoft
20
services on Microsoft's impact list
Microsoft
48h
email timeout, extended so delayed mail is kept
Microsoft
None
evidence of malicious activity, Microsoft says
Microsoft
Microsoft first pointed to elevated load, then found it was not traffic: “a number of servers being unexpectedly unavailable; straining the remaining infrastructure”.3 Servers were failing automated health checks, and the failures may have come from the component that processes server health; Microsoft found no recent change that lined up with the start.4 At 22:09 UTC it said its actions had “not provided the anticipated relief”: a core process on the servers was being overwhelmed.4 Servers it restarted could fail again once traffic returned, so it rebuilt some with a previous configuration and limited which traffic reached them.5
Twenty-one hours in, Microsoft reported recovery but no all-clear
Microsoft's own status posts on incident EX1550543 and MO1550821, 12–13 November 2026, in UTC (IST in each detail)
| Date | Event | Detail |
|---|---|---|
| 12 Nov, 17:54 UTC | Exchange mailboxes fail | Americas first; 11:24pm IST |
| 12 Nov, 18:07 UTC | Any region | 11:37pm IST |
| 12 Nov, 19:31 UTC | Servers unavailable | Not a traffic surge; 1:01am IST |
| 12 Nov, 22:09 UTC | No relief yet | A core process overwhelmed; 3:39am IST |
| 13 Nov, 00:06 UTC | Servers fail again | Rebuilt on an older configuration; 5:36am IST |
| 13 Nov, 10:28 UTC | 48-hour mail timeout | Capacity not yet at baseline; 3:58pm IST |
| 13 Nov, 14:00 UTC | Queues near normal | Email backlog nearly cleared; 7:30pm IST |
| 13 Nov, 14:56 UTC | Still degraded | Sustained improvements, no all-clear; 8:26pm IST |
Source: Microsoft 365 Status on X and status.cloud.microsoft · as of 13 November 2026, 8:30pm IST
The repair ran in rounds. By 19:12 UTC Microsoft had paused all deployments, moved traffic off the affected infrastructure and begun restarting servers. At 21:00 an alternative health-check method let a subset return, and it prepared automated systems to detect and restart servers that stopped responding.7 Overnight it adjusted traffic protocols, redistributed traffic and blocked some traffic outright; at 04:36 UTC that gave partial recovery, though not “sustained recovery”. By 07:44 its traffic changes were showing “positive results”, and it extended them to more regions.7
Microsoft’s list explains how one service reached twenty: the features hit are those “that interact with Exchange Online and email services”, while parts that do not depend on it kept working.1 Anything that reads mail, calendars or contacts through Exchange failed: Outlook on the web and desktop, mobile sync, Graph API calls, and Copilot’s access to work data. Teams calls, meetings and chats mostly worked, but scheduling, invites and live events did not; SharePoint files opened, though external sharing and Exchange-backed features could fail. Purview’s labelling, DLP and eDiscovery, the Defender portal and Intune check-ins were hit too.1 At 13:32 UTC Microsoft reported broad recovery in North America, sustained improvement in much of Europe and only “encouraging recovery signals” in Asia Pacific.6 In India that meant all of Friday’s working day. Microsoft has not said how many users were affected.
Earlier on Thursday a separate Teams incident, TM1550488, disrupted messaging in North and South America from 14:45 to 15:53 UTC; Microsoft has not said whether the two are related, BleepingComputer reported.8
Microsoft’s posts point to status.cloud.microsoft when the admin centre does not load. For Power Apps and Field Service, use the web app, and do not sign out, clear app data or reinstall. In Power BI and Fabric, removing a sensitivity label lets an export finish, where policy allows.1 Mail is held for 48 hours rather than returned, so a late message may still arrive.6 Amazon’s Tokyo fault and Google’s London outage were zone failures; this one crossed regions.
Microsoft also warned that Defender for Office 365 checks relying on Purview DLP and labelling signals could be delayed or fail, and that audit searches and eDiscovery exports could break.1 The root cause will come in the post-incident report under MO1550821 in the admin centre’s Service health.
Sources
Disclosure. TechBag is a software reseller: it earns when companies buy through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.