Microsoft's Exchange Online, the email and calendar system behind Outlook for business customers, began recovering at 11:20 UTC today, according to network data published by Kentik, after running about 85% below expected traffic levels since around 17:35 UTC on Thursday, November 12, 2026. By 13:25 UTC, traffic to the service was running about 19% above expected as queued mail and mailbox syncs caught up. Microsoft's public status page, last updated at 14:56 UTC today, reported "sustained improvements in service availability" but still labelled Microsoft 365 for business and enterprise customers as degraded.

In Short

Microsoft's business email service went dark for nearly 18 hours from Thursday and came back on Friday morning UTC, with independent network data from Kentik and Cloudflare showing both the collapse and the recovery. Companies, governments and AI assistants that read mail through Microsoft 365 lost access to inboxes and calendars in dozens of countries, from Tokyo ministries to European exchanges, while the EU's own institutions reported almost no impact. The data shows devices opening up to 70% more connections to Microsoft than normal while responses fell by about 73%, the retry pressure that kept recovering servers from staying up. Microsoft has extended its email timeout to 48 hours so delayed messages are not lost, and the root cause will only be confirmed in a Post-Incident Report the company has promised once mitigation is complete.

Nearly 18 hours, measured from outside Microsoft

PPC Land's first report on the incident, published early today, was built on Microsoft's own status page and gave no clear view of how far traffic had actually fallen. That picture now comes from outside the company.

Doug Madory, director of internet analysis at Kentik, posted charts on X today that track traffic to Exchange Online through the outage. According to the first chart, traffic to the service "ran about 85% below expected levels after the outage began around 17:35 UTC (12:35 PM ET) on Nov 12, 2026." It began recovering around 11:20 UTC today, and "by 13:25 UTC was running about 19% above expected levels." Kentik defines expected traffic as the level at the same time a day earlier, scaled to match traffic before the outage. The same chart shows no comparable drop for the other Microsoft 365 services Kentik tracked: Office 365, Teams, and SharePoint and OneDrive.

"Microsoft's Exchange Online is back, and then some," Madory wrote. "After ~19 hours running ~85% below expected, traffic began recovering at 6:20 AM ET (11:20 UTC). By 8:25 AM ET it was running ~19% above expected as queued mail and mailbox syncs caught up."

The duration needs a note. In an earlier post on the same recovery, Madory put the period of depressed traffic at about 18 hours. The times on Kentik's own charts, from about 17:35 UTC on Thursday to 11:20 UTC today, give 17 hours and 45 minutes, PPC Land calculates. Counted to Microsoft's 14:56 UTC status update today, which still described the service as degraded, the incident had run for 21 hours and 21 minutes.

When it actually started

The network data also moves the start of the outage. PPC Land's first report cited Windows Latest, which said Microsoft's admin center advisory, reference MO1550821, put the start at around 1:25 PM ET on Thursday, or 18:25 UTC. Cloudflare's charts mark the start of MO1550821 at about that time. Every external measurement places the onset earlier.

Cisco's ThousandEyes said on X that "beginning around 17:30 UTC" it observed availability issues affecting Microsoft 365 services globally, with users meeting connection resets, connection refusals and response timeouts. Kentik marks the outage start at about 17:35 UTC and Cloudflare at about 17:45 UTC. Anthropic opened an incident on its own status page titled "Elevated errors affecting the Microsoft 365 connector" at 12:52 p.m. ET, or 17:52 UTC, according to ZeroHedge. Microsoft's first public post on its Microsoft 365 Status account on X followed at 17:54 UTC: "We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas."

On that evidence, the advisory time cited in PPC Land's first report appears to reflect when Microsoft opened MO1550821, while traffic had begun falling about 50 minutes earlier.

Where the traffic went

A second Kentik chart breaks Exchange traffic down by location, using where the sending addresses geolocate, which Kentik says are mostly Microsoft's own servers. "When the outage hit, Exchange traffic from Microsoft's major locations in the Americas and Europe nearly vanished," Madory wrote. "Asia-Pacific sites came back partway overnight, and a second recovery wave lit up London, Chennai and Johannesburg around 9 AM ET."

The chart sorts locations into four groups. Campinas, Santiago, Phoenix, Madrid and Zurich went dark and had shown little recovery by the end of the chart. Vienna and Gävle in Sweden picked up traffic after the outage began, part of what Kentik describes as European and Asia-Pacific sites picking up some of the load overnight. Pune, Marseille, Sydney, Melbourne and Tokyo came back partly overnight. The largest group, including Chicago, San Antonio, Boydton, Des Moines, London, Dulles, Paris, Toronto, Amsterdam, Frankfurt, Dublin and Oslo, only returned after about 11:20 UTC.

A retry storm

The third chart helps explain why the recovery took so long. According to Kentik, "devices opened up to 70% more connections to Exchange than expected, while connections carrying responses from Microsoft fell to about 27% of normal." The measurement covers TCP port 443 flows, the standard port for encrypted web traffic, as 35-minute rolling averages.

Connection attempts peaked shortly after 18:00 UTC on Thursday, eased, spiked again around 00:30 UTC and then fell to around or slightly below expected levels overnight. Responses stayed roughly three quarters below normal until recovery began at 11:20 UTC. "That's the retry pressure Microsoft described as overwhelming servers once they came back online," Madory wrote.

What Cloudflare saw

Cloudflare Radar, the company's public measurement service, published a thread today based on requests that Cloudflare's network sends to Microsoft 365 servers. Its charts compare the outage with the same period a week earlier.

From about 17:45 UTC, according to Cloudflare, requests to the category it labels "Microsoft 365 Common and Office Online" fell sharply and had almost stopped by about 19:00 UTC. "Requests to Exchange Online went the other way and tripled, likely clients and apps retrying," Cloudflare wrote.

Many of those requests went unanswered. Cloudflare quoted Microsoft's own explanation that "a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests," and said this was visible in its data from about 17:45 UTC. Its chart of requests with no response shows Exchange Online jumping from a low baseline to a peak in the early evening UTC and staying elevated through Friday morning.

When servers did answer, it was often with an error. According to Cloudflare, most Exchange Online responses were server errors, the 5xx class of HTTP status codes, until about midnight UTC. At Entra ID, Microsoft's sign-in service, which handles single sign-on for Microsoft 365, approximately one in three requests failed.

Responses that did arrive were slow. Exchange Online's median time-to-first-byte, a measure of latency that Cloudflare describes as "the wait before the server starts responding," rose from about 10 milliseconds to 90 milliseconds between 19:15 and 20:30 UTC. Entra ID's rose from 155 milliseconds to over 200 milliseconds.

Recovery came later in Cloudflare's data than in Microsoft's statements. Microsoft reported limited recovery from about 23:00 UTC on Thursday, but "in what we saw from Cloudflare's network, successful Exchange Online responses were still near zero at 09:00 UTC on Nov 13, and Entra ID errors hadn't gone away." By 13:00 UTC today, server errors from Microsoft 365 servers were falling and successful responses were returning to normal, according to Cloudflare. "Entra ID and Exchange Online are recovering," it wrote.

Two datasets, one pattern

The two measurements are not the same thing. Kentik measures traffic volumes against an expected baseline and saw Exchange traffic fall 85%. Cloudflare counts requests and saw Exchange requests triple. Both describe clients that kept trying to connect while Microsoft's servers stopped answering, and Kentik's connection chart shows the same split directly. The vendors also group Microsoft's services differently: Kentik saw no comparable drop in what it labels Office 365, while Cloudflare saw requests to "Microsoft 365 Common and Office Online" almost stop. Neither company can see inside Microsoft's servers, and neither claims to identify the root cause.

How Microsoft explained it, update by update

Microsoft's Microsoft 365 Status account on X posted a run of updates on Thursday evening UTC, all referring administrators to incidents EX1550543 and MO1550821 in the Microsoft 365 admin center, or to the public page at status.cloud.microsoft for those unable to reach the admin center.

Within roughly the first hour after its 17:54 UTC post, Microsoft widened the scope: "we've confirmed the issue may affect Microsoft 365 service connectivity for users in any region." It then said it had "determined a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors," and that it had "begun redistributing connection traffic across our broader worldwide infrastructure to help balance the load."

Between about 19:00 and 20:00 UTC, the posts became more urgent. "We're aggressively pursuing all pathways to reduce impact. We've paused all deployments, we're moving additional traffic off the affected infrastructure, and we're restarting affected servers to return them to service," Microsoft wrote. The next update ruled out one explanation: "We determined the elevated load isn't driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure."

Microsoft then pointed to health checks. It was "testing a configuration change to address a problem that's causing servers to fail automated health checks and become unavailable," and had initiated a restart of all affected servers. A later post said "the failed health checks may originate from a specific component that's responsible for processing server health," and that Microsoft had "validated an alternative service health check method, which allowed a subset of affected servers to successfully return to service." It said it was preparing "automated recovery systems to continually detect and restart unresponsive servers."

Late on Thursday UTC came the admission that the plan had not worked. "We're opening all available pathways to restore service, as our actions taken thus far have not provided the anticipated relief," Microsoft wrote, in a post viewed 10 million times according to X's counter. "We found a core process on affected servers is becoming overwhelmed, causing capacity loss." Engineers were isolating part of the infrastructure, restarting components and reintroducing traffic to confirm stability before applying the change more broadly. Around midnight UTC, Microsoft said it was returning a portion of affected servers to service, shifting traffic to alternate routes where possible and "observing limited recovery," adding that "users may experience a gradual recovery as their clients reconnect."

According to ZeroHedge, Microsoft also warned overnight that servers it had brought back "can become unresponsive again once they receive traffic," and several did. ZeroHedge reported that Microsoft patched an authentication and routing component. It also reproduced a Microsoft post stating: "We've monitored the status of the changes applied to improve serviceability and confirmed they're not taking as expected. We're identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances."

A change, or no change?

Two of Microsoft's posts sit uneasily together. Around 20:00 to 21:00 UTC, the company wrote: "We've not identified any recent change correlated with the start of impact." About an hour later, it said it was "assessing whether reverting a small number of recent configuration updates we identified could help accelerate recovery." The thread does not say whether those updates were reverted or whether reverting them helped.

The traffic question, again

PPC Land's first report noted that the 05:46 UTC status page referred to a "traffic influx," which sat awkwardly beside Microsoft's statement that the load "isn't driven by an increase in traffic." The record now contains a third formulation. According to ZeroHedge, Microsoft first said on Thursday that it was reviewing "an unexpected increase in a specific type of service traffic" to see whether it was contributing, before ruling that out.

The network data offers one way to read these statements together. Organic demand did not rise, but the clients that could not connect kept retrying, and that retry traffic landed on a shrinking pool of working servers. Madory draws exactly that link. Whether the retries were the cause of the original server failures or a consequence of them is a question only Microsoft's Post-Incident Report can settle.

The climb back on Friday

Microsoft's status updates through Friday morning tracked a phased recovery. Portuguese newspaper Observador, which relayed the updates in Lisbon time, the same as UTC in November, reported the sequence. At about 09:15 UTC, Microsoft said it was seeing first signs of stabilisation, but that service capacity had not returned to normal and stability varied as traffic was cautiously reintroduced. The mitigation process, it said, involved diverting traffic, restarting, remediating and gradually returning infrastructure to service under close monitoring.

At 10:00 UTC, Microsoft said recovery actions had progressed in phases, with global telemetry and customer reports showing gradual improvement, while service health remained unstable. At 11:00 UTC, it reported completed actions in parts of the affected infrastructure in Asia-Pacific and improvements in mailbox access and the processing of delayed email. At 12:00 UTC, it described encouraging progress in Europe, said Japan was comparatively more stable and North America was also improving, and said it was prioritising the processing of accumulated queues, extending the timeout for email to 48 hours so delayed messages would be preserved.

At 13:00 UTC, according to Observador, Microsoft reported broader improvements in North America, sustained improvements across much of Europe and encouraging signs in Asia-Pacific. By 14:00 UTC, which ZeroHedge gives as 9 a.m. ET, Microsoft said email queues were "significantly reduced and approaching normal levels," though some users could still meet intermittent access problems or delayed mail.

The public Service Health Status page, last updated at 2:56:52 PM UTC today, opened its current status with: "We're observing sustained improvements in service availability as recovery progresses across affected Microsoft 365 services." The business section remained marked "Service degradation." Microsoft had not declared the incident resolved at that update.

What changed on the status page

The list of affected services has grown and shifted since PPC Land's first report, which counted 19. The 14:56 UTC page lists 20.

Microsoft Power Apps is new. According to Microsoft, "Users may be intermittently unable to sign-in to the Power Apps or Field Service mobile apps." Microsoft suggests the web versions as a way around the problem, and says users who are already signed in "can potentially avoid impact by not signing out, clearing app data, or reinstalling while the issue is ongoing."

SharePoint Online now carries an additional problem: some users may have issues sharing files with people outside their organisation where external sharing is permitted. The Microsoft Defender for Office 365 entry has changed. The earlier version described failures in Safe Links, which caused rewritten links in email to fail to open. The current entry no longer mentions Safe Links and instead describes delays or failures in policy evaluation for experiences that rely on Purview data loss prevention and Information Protection signals, along with problems for administrators accessing some features in Microsoft Defender for Cloud Apps.

The consumer section is inconsistent. Its Microsoft 365 card, last updated at 14:10 UTC, says: "Our recovery efforts to restore service health throughout the affected environment is ongoing and may take additional time to resolve." It says the issue impacts "Outlook.com, OneDrive, OneNote, Microsoft To Do, Teams, and Microsoft 365 for the web." The product list beneath it shows Outlook.com, OneDrive, Microsoft To-Do, Microsoft Teams Free and Office for the web as "Operational." Microsoft Azure showed no issues.

Who felt it

User reports on Downdetector, which counts complaints rather than confirmed failures, give a sense of the reach. According to POLITICO, Downdetector reported issues in at least 74 countries and logged nearly 140,000 reports of Outlook problems at its peak. ZeroHedge reported that outage reports peaked at 19,650 a minute across five Microsoft services, against fewer than 15 on a typical Thursday.

Markets and companies

Trading desks fell back on phones, WhatsApp and fax machines, according to Bloomberg as reported by ZeroHedge. Deutsche Bank's email access was patchy, traders in Singapore said some banks could not close financing deals, and Euronext and Nasdaq both reported email problems. Reuters reported that the outage halted at least one bond repurchase in Europe, and bankers at Goldman Sachs and Morgan Stanley in Hong Kong told CNN they could not reach email or Teams.

Corporate reporting was disrupted. Richemont, the owner of Cartier, delayed first-half results due at 06:00 GMT today before publishing later in the morning, according to ZeroHedge. Electric truck maker Workhorse moved its results to November 16, British insurer Aviva set up backup arrangements for its earnings calls, and Maersk warned customers that email updates could be delayed. Air India rerouted its email, while Alaska Airlines and IndiGo said email-based customer service channels were affected. Observador also named Akasa Air among airlines reporting impact on email services.

Governments

In Tokyo, the finance ministry could not receive email for most of the day and ministries pinned up paper notices to give journalists the day's schedule, according to ZeroHedge. Chief Cabinet Secretary Minoru Kihara confirmed that communications between ministries were disrupted. In Australia, the intelligence agency ASIO and the Australian Federal Police were among those affected, Service NSW centres in regional New South Wales closed and the state's online bail court was disrupted. Tony Burke, Australia's home affairs and cyber security minister, said Microsoft itself had likened the disruption to the 2024 CrowdStrike outage, the faulty update that crashed Windows machines worldwide on July 19, 2024.

Singapore's government email went down, the Philippines' Supreme Court said some operations were affected, and New York City Emergency Management warned that email to city agencies could be delayed. In Toronto, the Unity Health hospital network declared a code grey, its signal for an infrastructure failure, while saying patient care was not affected.

In Portugal, the government confirmed that its own work and that of the public administration were affected, according to Observador. The government said that use of Microsoft 365, which most public administration services rely on, had been restricted since Thursday, November 12, but that normal operations were being maintained through secure alternative means. Its General Secretariat said Microsoft had confirmed it was working to restore services across Europe and would prioritise public administration. The health ministry's shared services body, SPMS, confirmed that entities under the ministry were affected. According to Observador, the failure hit hospital communication and management but not patient care, and the national emergency medical institute INEM said its operational activity was not affected. Ema Paulino, president of the national pharmacy association ANF, told Observador that pharmacies saw no disruption because their dispensing systems do not use Microsoft.

The EU institutions that carried on

The European Union's own institutions reported little impact. "The impact ... is very limited and does not affect our operations," European Commission spokesperson Thomas Regnier told POLITICO, describing a "minor impact on a limited number of applications, such as the slowness of SharePoint." Outlook and Teams were "fully operational," he said. A Council of the EU official said Outlook and Teams were "working on our side," and the European Parliament's press service said it was unaffected. POLITICO did not report why the institutions were spared.

The same report noted that the German state of Schleswig-Holstein moved about 40,000 mailboxes from Microsoft Exchange and Outlook to open-source alternatives in 2025. Its digitalisation minister, Dirk Schrödter, told POLITICO that disruptions like this one "must be taken very seriously," whatever software a state uses. "We must be able to intervene ourselves at any time if problems arise," he said.

The assistants went quiet too

Microsoft's AI products failed with the inbox. The status page says "Copilot experiences may be unable to access work data such as email, calendar, and files," and that users may be unable to load Copilot Chat at all. Requests to Microsoft Graph, the interface outside software uses to reach Microsoft 365 data, that touch Exchange Online data "such as mail, calendar, and contacts, may time out."

Third-party assistants that rely on that interface were hit. According to ZeroHedge, Anthropic's status page said on Thursday evening that its Microsoft 365 connector's mail, calendar and search tools were "still failing for most requests," that some users "may not be able to open" the Claude for Outlook add-in, and that the cause was "a Microsoft 365 service incident." OpenAI also reported errors affecting its Microsoft 365 connectors, ZeroHedge reported, citing FinanceX.

The timing is awkward for Microsoft. Its Ignite conference opens in San Francisco next week with a programme built around Agent 365, its system for managing AI agents across a company's apps and data, according to ZeroHedge.

Microsoft executive Charles Lamanna addressed the outage on X. "We regret that today's outages caused disruptions for our customers, and we are working to address the issue," he wrote. "We will continue to share more information as soon as we have it, and for now I can confirm that there is no indication this is the result of malicious or cyber activity." Microsoft said on Friday morning, according to POLITICO: "At this time, we have no evidence of malicious activity associated with this incident. We will continue to treat this with urgency until full mitigation."

What 17 hours and 45 minutes means for service credits

PPC Land's first report set out the Exchange Online service level terms as described by Windows Latest: a monthly uptime commitment of 99.9%, with a 25% service credit below that level, 50% below 99% and 100% below 95%, measured in user-minutes. November has 30 days, or 720 hours. A user unable to reach a mailbox for the full 17 hours and 45 minutes in Kentik's data would have lost about 2.5% of the month, leaving availability of about 97.5%, PPC Land calculates. Counted to the 14:56 UTC status update, the figure is about 97.0%. Both sit between the 99% and 95% thresholds. Because the measure is calculated across all users in a tenant, and not every user was affected for the whole period, no individual tenant's position can be read from these figures.

Why this matters for the marketing community

For marketers, the first effect is on email itself. Messages sent to Microsoft 365 business inboxes during the outage were delayed, and Microsoft extended its timeout to 48 hours so they would not be lost. Kentik's 19% surge above expected traffic this morning is that backlog arriving at once. B2B newsletters, campaign briefs, approval chains and invoices sent to affected inboxes on Thursday evening UTC would have landed hours late, compressing deliveries, opens and replies into Friday morning.

The second effect is on the AI tools agencies and in-house teams have been wiring into their workflows. Microsoft reported in October that Copilot daily users were up nearly 50 percent quarter over quarter, and in July that Microsoft 365 Copilot passed 30 million paid seats. The outage showed that those assistants, and the Claude and ChatGPT connectors that read the same mailboxes through Graph, depend entirely on a mail backend they do not control. An agent that schedules meetings, drafts replies or summarises a client thread stops when Exchange stops.

The third is concentration. In October 2025, a DNS failure in Amazon Web Services' US-EAST-1 region disrupted 142 AWS services for more than 15 hours. This week's incident was a single hyperscaler failing in a single layer, and it reached ministries, exchanges, hospitals and airlines on several continents. The scale is visible in Microsoft's accounts: Microsoft 365 commercial cloud revenue reached $27.78 billion in the September quarter, up 17%. In Europe, the outage lands in a debate that was already live. Amazon launched the AWS European Sovereign Cloud in January, and the European Commission's October 2025 cloud sovereignty framework gave legal independence from foreign governments only 10% of its score.

Finally, the incident shows how much of the public record of an outage now comes from third-party measurement. Cloudflare, which says it sits in front of roughly a fifth of web traffic, and Kentik published timelines, start times and recovery curves before Microsoft had closed the incident. Their data already moves the start time reported on Thursday by about 50 minutes. The Post-Incident Report, with what Microsoft has called "root cause and defense-in-depth actions," according to ZeroHedge, will show whether Microsoft's own account matches theirs.

Timeline

  • July 19, 2024 - A faulty CrowdStrike update crashes Windows machines at businesses worldwide
  • October 2025 - The European Commission publishes a cloud sovereignty framework that gives legal independence 10% of the score
  • October 19-20, 2025 - A DNS failure in AWS US-EAST-1 disrupts 142 AWS services for more than 15 hours
  • January 15, 2026 - AWS makes its European Sovereign Cloud generally available
  • July 29, 2026 - Microsoft reports that Microsoft 365 Copilot passed 30 million paid seats
  • October 8, 2026 - Cloudflare redesigns Radar, its public internet measurement site
  • October 28, 2026 - Microsoft reports Microsoft 365 commercial cloud revenue of $27.78 billion, up 17%, and Copilot daily users up nearly 50% quarter over quarter
  • November 12, 2026, about 17:30 UTC - ThousandEyes observes availability issues affecting Microsoft 365 services globally
  • November 12, 2026, about 17:35 UTC - Exchange Online traffic begins falling to about 85% below expected, according to Kentik
  • November 12, 2026, about 17:45 UTC - Cloudflare sees requests to Microsoft 365 Common and Office Online fall and Exchange Online requests triple
  • November 12, 2026, 17:52 UTC - Anthropic opens an incident for elevated errors affecting its Microsoft 365 connector, according to ZeroHedge
  • November 12, 2026, 17:54 UTC - Microsoft posts its first public update, citing Exchange Online mailbox access issues in the Americas
  • November 12, 2026, about 18:25 UTC - Advisory MO1550821 begins, according to Cloudflare's chart annotations
  • November 12, 2026, 19:15 to 20:30 UTC - Exchange Online's median time-to-first-byte rises from about 10 to 90 milliseconds, according to Cloudflare
  • November 12, 2026, evening UTC - Microsoft pauses all deployments, says the load is not driven by more traffic, tests an alternative health check method and says its actions "have not provided the anticipated relief"
  • November 12, 2026, about 23:00 UTC - Microsoft reports limited recovery
  • November 13, 2026, 05:46 UTC - Microsoft's status page lists 19 affected services and a "traffic influx"
  • November 13, 2026, 09:00 UTC - Successful Exchange Online responses are still near zero in Cloudflare's data
  • November 13, 2026, 11:20 UTC - Exchange Online traffic begins recovering, according to Kentik
  • November 13, 2026, 12:00 UTC - Microsoft extends the email timeout to 48 hours to preserve delayed messages, according to Observador
  • November 13, 2026, 13:00 UTC - Cloudflare sees server errors falling and successful responses returning to normal
  • November 13, 2026, 13:25 UTC - Exchange Online traffic runs about 19% above expected as queued mail catches up, according to Kentik
  • November 13, 2026, 13:36 UTC - POLITICO reports that the European Commission, Council and Parliament were largely unaffected
  • November 13, 2026, about 14:00 UTC - Microsoft says email queues are approaching normal levels
  • November 13, 2026, 14:56 UTC - Microsoft's status page reports "sustained improvements" across 20 affected services, still labelled as degraded

Summary

Who: Microsoft and the business, government and enterprise customers of Microsoft 365 who rely on Exchange Online for email and calendars, along with third-party AI assistants, including Anthropic's Claude and OpenAI's ChatGPT connectors, that read Microsoft 365 data. Network measurements came from Kentik, Cloudflare Radar and Cisco's ThousandEyes.

What: An outage in which Exchange Online traffic ran about 85% below expected levels for 17 hours and 45 minutes, according to Kentik's charts, while devices opened up to 70% more connections than normal and Cloudflare saw Exchange requests triple as clients retried. Service began recovering at 11:20 UTC today and traffic ran 19% above expected as queued mail caught up. Microsoft extended its email timeout to 48 hours and reported sustained improvements, without declaring the incident resolved.

When: The outage began at about 17:30 to 17:45 UTC on Thursday, November 12, 2026, according to ThousandEyes, Kentik and Cloudflare, about 50 minutes before the 18:25 UTC advisory start reported earlier. Recovery began at 11:20 UTC today, Friday, November 13, and Microsoft's status page was last updated at 14:56 UTC today.

Where: Microsoft 365 infrastructure worldwide, starting in the Americas. Downdetector logged reports in at least 74 countries, according to POLITICO. Governments in Japan, Australia, Singapore, the Philippines and Portugal were affected, while the European Commission, Council and Parliament reported little or no impact.

Why: Microsoft says servers failed automated health checks and became unavailable, straining the rest of the infrastructure, and that a core process responsible for establishing secure connections became overwhelmed. Its first fixes did not provide the anticipated relief, and recovering servers could become unresponsive again once traffic returned. The network data shows the retry pressure behind that pattern. Microsoft has said it sees no malicious activity and has promised a Post-Incident Report with the root cause.