Outlets relay five Microsoft explanations of the 365 outage; its public status page, as read, printed none

23 hours after the 16:17 UTC stamp, Microsoft's public page still read Service degradation

Three outlets that quote Microsoft's service health updates, LazyAdmin, UC Today and WindowsForum, date the Exchange Online incident EX1550543 at 16:17 UTC on Thursday 12 November 2026. Microsoft's public status page, status.cloud.microsoft, was read by this site from 15:18:10 to 15:18:18 UTC on Friday 13 November. Its Microsoft 365 (Business or Enterprise) entry still read "Service degradation" and had last been updated at 14:56:52 UTC. From the relayed 16:17 stamp to that last update is 22 hours 39 minutes 52 seconds, and to the start of the read 23 hours 1 minute 10 seconds (both derived).

What this does not establish. The public entry names no service and prints no incident number, so it cannot be tied to EX1550543 from the page alone. The 16:17 stamp is three relays' date for when the incident was opened, not shown to be when mailboxes stopped working: the earliest user reports in the saved relays are at 17:50 UTC, 1 hour 33 minutes later (derived). The words "Service degradation" are a status label, not a measure of how many users or how badly. Nothing after 15:21 UTC on 13 November is included. This is an availability incident. No saved page reports a breach: SecurityWeek wrote on 12 November that Microsoft "has disclosed no evidence of a cyberattack", and other relays below say Microsoft stated it was not aware of malicious activity.

What moved. As relayed by SecurityWeek, BleepingComputer, LazyAdmin, UC Today, Chasms and WindowsForum, Microsoft's account of what was wrong went through five successive explanations (a derived count: this site's grouping of the relayed updates, tabulated below). The stamps relays print for them run from 18:45 UTC on Thursday, a Mashable report as relayed by WindowsForum, to 02:00 UTC on Friday, SecurityWeek's stamp: 7 hours 15 minutes (derived), though neither end is Microsoft's own time. One move reversed an earlier statement, from no recent change matching the start of the impact to reverting a recent change that correlates with it. The public status page, read three times on 13 November, printed none of the five.

The source ladder. Microsoft's own updates live in two places this site cannot read: the Microsoft 365 admin center, which sits behind a sign-in, and a Microsoft account on X, which this site does not read. So every Microsoft update quoted here is relayed by a named outlet with that outlet's own timestamp. Three pages were read directly, each in a browser tab on 13 November: Microsoft's public status page, the OpenAI status page and the Claude status page. The status page host answered 401 to a script request for its robots.txt and OpenAI's main site answers 403 to scripts, so no script request was made to either host; the pages loaded publicly in a browser. Everything else is a relay, and some of it is a relay of a relay: WindowsForum, a community site, carries updates attributed to other outlets, and two of the three threads saved carry a label reading "AI-assisted supplemental research". The third thread, WindowsForum on MO1550821, is the only saved page that carries the Reuters and Techaeris Downdetector figures and a few stamps cited below.

Who sells what. Microsoft sells Microsoft 365, writes its own status posts and, per relays, will write the post incident report. The two AI vendors whose status pages are quoted, OpenAI and Anthropic, are themselves downstream customers of Microsoft's service and write their own status text. The first version of this article, published at about 12:19 UTC on 13 November, was built from the status page and SecurityWeek only. This version replaces it.

What the saved record establishes: read directly, relayed, not stated

Three kinds of statement sit in the record, and they are not equal. A page this site read itself shows what it printed at the time and nothing more. A relay shows what an outlet says Microsoft posted, in the outlet's words and with its clock. A statement that is in neither is not stated. The table keeps the three apart.

The timeline in UTC, with every relay's own stamp

Every time below is in UTC. Where a relay printed a time in US Eastern or Pacific, the conversion is this site's (Eastern is UTC minus five hours and Pacific minus eight, because US daylight time ended on 1 November; WindowsForum notes the same). The diagram shows six periods; the table gives each stamp as the relay printed it. Where two relays print different times for what looks like the same update, the next section keeps the difference.

Zoom

What the timeline shows. The Exchange incident and the broader one are 2 hours 9 minutes apart on the relayed stamps (16:17 to 18:26, derived). The first Claude status stamp, 17:52 UTC, is 1 hour 35 minutes after 16:17, 34 minutes before 18:26 and 6 minutes after the 17:46 UTC stamp that a WindowsForum mirror carries (all derived). That places the first third party notice between the two Microsoft incident stamps. It does not say what Microsoft knew when.

The explanation moved: five rungs, one reversal

Read in order, the relays give five explanations for what was wrong. The grouping is this site's (derived count): each row is one explanation as relayed, with the relays that print it and their stamps. Some rows are refinements of the one before and one is a reversal; the table says which.

Zoom

The reversal, as relayed. The WindowsForum mirror says Microsoft at 19:43 to 19:57 GMT first suggested a recent change to the health check component might be involved, then said it found no recent change that matched the start of the impact. Hours later, SecurityWeek writes that Microsoft "began rolling back a recent network configuration change that coincided with the start of the disruption". UC Today quotes the same update as reverting "a recent network configuration change that correlates with the start of impact". WindowsForum writes that it did so "despite saying hours earlier that it had found no such change". LazyAdmin: "Last night it said it hadn't found any change that matched, so that's a shift." It adds "But it's not a confirmed cause."

On the relayed stamps the two statements are 6 hours 3 minutes to 6 hours 17 minutes apart (19:57 or 19:43 to SecurityWeek's 02:00, derived). SecurityWeek's stamp is its own update time, and LazyAdmin has the restart update at 01:50, so the real gap could be a little shorter or longer. What the relays do not establish: that the "small number of recent configuration updates" BleepingComputer says Microsoft examined at 23:57 UTC, the health check component change and the network change are one change or three; whether any of them started the outage; or why Microsoft's view changed.

Rung 2 also corrects a reading. WindowsForum notes that Microsoft had been examining whether the load reflected more requests or a change in routing, and the later statement ruled out more traffic. LazyAdmin's 04:57 UTC item says Microsoft was scaling up virtual machines for "a surge in traffic from its routing services to the backend servers", which reads as traffic returning to restored servers, in LazyAdmin's paraphrase. This site does not read it as contradicting rung 2, and records it as relayed.

Where the relays print different times or words for the same update

Relays stamp events by their own clock and report time, not always by when Microsoft posted. Where two relays differ for what looks like one update, the difference stays a difference. No winner is picked, and this site cannot tell which stamp is closest to Microsoft's post. Gaps are derived from the converted stamps.

Two further differences are not about clocks. First, rung 3: SecurityWeek says Microsoft was "testing a workaround that bypasses the component responsible for processing those checks", while Chasms, quoting a Penn extract of the 3:08 pm ET update, says Microsoft was deploying "a targeted change to bypass the failing component on a subset of servers". They read as one update with two wordings, not two actions. Second, the BleepingComputer page's own link list headlines a different Patch Tuesday count (1,235 flaws) from SecurityWeek's 1,094 vulnerabilities; neither article was read in full on that point, and this site draws no link between Patch Tuesday and the outage.

The public status page, read three times

The page was saved three times on 13 November: a text transcription at about 11:18 UTC, a PDF at 11:20:53 UTC, and a text read at 15:18:10 to 15:18:18 UTC with Show details and Show products expanded. Across all three the business entry's headline and the admin center sentence are the same words. Only the last updated time moved: 11:04:50 UTC at the first read, 14:56:52 UTC at the third, 3 hours 52 minutes 2 seconds later (derived). The consumer entry's moved from 10:26:34 to 14:10:05 UTC, 3 hours 43 minutes 31 seconds later (derived). At 15:18:10 the business entry was 21 minutes 18 seconds old (derived).

The headline is one incident's title. Chasms prints the Penn extract's title for MO1550821 as "Users may be unable to connect to multiple Microsoft 365 services", word for word (11 words, derived) the page's headline. The title of EX1550543, as WindowsForum and Chasms print it, is longer and names Exchange Online mailboxes. So the public entry carries one incident's title without its number, and nothing at all for the other. That is this site's comparison of printed strings; the admin center was not read.

What the page says about itself. Its one sentence explains why the issue is posted: Microsoft 365 administrators "may be unable to access the admin center to get Service health information". The page does not say which administrators, which tenants or since when.

Relays describe more than the page printed. XDA, published at 9:36 AM EST (14:36 UTC), says new information on the status page has been posted frequently since the outage started, and excerpts what it calls the latest health status update: "broader improvements now observed in North America and sustained improvements across much of Europe". That is recovery wording, not a cause. At the 15:18 read, with details expanded, the business entry printed only its update time and the admin center sentence. The saved reads do not show where XDA's excerpt came from, and this site does not resolve the difference.

Could readers reach the page? WindowsForum relays that the public page would not load for some. Relaying ZDNET, it says the page had not loaded at 2:21 p.m. Eastern (19:21 UTC) and was accessible again at 3:05 p.m. (20:05 UTC): 44 minutes (derived). Relaying a Fresno outlet, it says Microsoft's status checker was unavailable at 9:58 a.m. PT (17:58 UTC) and still at 10:03 (18:03 UTC). It also says users on X reported the page would not load. These are relays of user reports and unverified here. Chasms says its own re-fetch of the page returned HTTP 200, and all three reads by this site loaded it.

Who else was hit, and what the relays say still worked

Two AI vendors' own status pages, read at 15:20 UTC, list Microsoft 365 connector incidents. OpenAI's page reads "new connections may be broken and tools are not working as expected" and "Ongoing for 20 hours". On Claude's page the incident titled "Elevated errors affecting the Microsoft 365 connector" carries five stamps, from 17:52 UTC on 12 November to 22:23 UTC. The last one says the issue is "caused by a Microsoft 365 service incident", and the incident was listed as unresolved at 15:20:53 UTC. The last Claude stamp was 16 hours 57 minutes 53 seconds before the read, and its first, 17:52, was 4 hours 31 minutes before its last (both derived).

Zoom

The counts disagree in ways that a different time or a different Downdetector page would explain. The figure at 18:12 UTC (over 130,000) is about double the figure four minutes earlier (over 65,000 at 18:08 UTC), and Reuters' 138,058 peak is 2.12 times 65,000 (all derived). This site cannot say which is right, and the figures say how loudly people complained, not how many were affected. Relays also name public bodies as affected: UC Today lists health, central bank, regulator, exchange and university users in the UK and Europe, and WindowsForum relays municipal and county offices in Canada and the United States. None of those organisations' own notices was read, and none is a Microsoft statement.

What Microsoft has and has not said about cause and security

Nothing saved from Microsoft states a root cause. What the relays print is a set of claims at different levels of certainty. The table sorts them by who made them: Microsoft as relayed, a relay's own reading, a second hand report this site did not read, or opinion.

Security, as far as the record goes. SecurityWeek says "Microsoft's service advisories have not linked the vulnerability to the Exchange Online outage", referring to CVE-2026-124194, an Outlook spoofing flaw it says Microsoft reports as exploited, fixed in the 10 November Patch Tuesday that SecurityWeek says addressed 1,094 vulnerabilities. This site read neither the CVE record nor the advisories and draws no link. A relayed statement that Microsoft is not aware of malicious activity is a statement of what Microsoft knew when it was made. It does not close the question and it is not a post incident finding.

Every explanation is provisional. Per UC Today and WindowsForum, Microsoft has promised a full post incident report after mitigation. As far as the saved pages show, none had been published by the 15:21 UTC reads, and until one is, any single explanation above is, in WindowsForum's words, still provisional.

Recovery as relayed, and what delayed mail means

Recovery is relayed in steps that do not agree on every clock (see above). UC Today, in GMT, prints five Microsoft updates on Friday 13 November: 07:24, 08:09, 09:03, 09:57 and 11:01. LazyAdmin has 04:22 and 04:57 UTC. BleepingComputer's update stamped 8:05 AM ET (13:05 UTC) says "We're seeing encouraging recovery progress", and adds that "Some users may still experience intermittent issues".

The 48 hour timeout. BleepingComputer says Microsoft "extended its email timeout window to 48 hours to help preserve delayed messages". UC Today and WindowsForum say the same. What that states: a longer period in which senders and queues keep trying. What it does not state: how many messages are delayed, how many have been delivered, or that every one will be. A third WindowsForum thread, relaying UNILAD Tech, says the window moved from 24 to 48 hours and that the extension does not guarantee delivery because other providers may apply their own retry limits. LazyAdmin says "your mail is delayed, not lost" and WindowsForum writes "Delayed mail is being held, not discarded." Those are the relays' readings; no saved page prints a count of undelivered or lost messages, and this site reads "held, not lost" as the relays' wording, not as a Microsoft guarantee.

Still not over at the read. The business entry on the public page was Service degradation at 15:18:18 UTC, 23 hours 1 minute 18 seconds after the relayed 16:17 stamp (derived). OpenAI's connector incident was ongoing at 15:20:48 and Claude's unresolved at 15:20:53. BleepingComputer's last update was at 13:05 UTC and UC Today's at 12:00 GMT. Anything Microsoft posted after about 15:21 UTC is not included.

What the record does not establish

Service credits: LazyAdmin's reading, and the arithmetic

Everything in this section is LazyAdmin's reading of Microsoft's Online Services SLA. The SLA document itself was not read. LazyAdmin says the SLA promises "99.9% uptime per month for Exchange Online, Teams and SharePoint", credits of 25%, 50% and 100% at the thresholds below, claimed by the administrator through a service request in the admin center, with a deadline of the end of the calendar month after the outage, so 31 December 2026 for a November outage. The credit comes off a future invoice, not as a refund, it covers only the service that went down, uptime is counted in user minutes, and a tenant that bought through a CSP partner claims through the partner. WindowsForum, relaying PPC Land, gives the same three percentages.

What the elapsed time shows. From the relayed 16:17 UTC stamp, 7.2 hours was passed at 23:29 UTC on Thursday, and 36 hours would be passed at 04:17 UTC on Saturday 14 November (derived). At the 15:18:10 read, 23 hours 1 minute 10 seconds had elapsed: more than 7.2 hours and less than 36. That is a statement about elapsed time since a relayed stamp, not about any tenant's downtime, which the SLA counts in user minutes. This site does not say what credit any tenant will receive.

What to do, in order

Microsoft's public page gives readers no advice beyond its own pointers. These steps are this site's suggestions, drawn from the gaps above. Where a relay says something similar, the item says so. They are ranked by what costs least and protects most.

Technical details

No indicators exist in any saved source: no addresses, domains, hashes, file names, commands, configuration or log lines. This is a service availability incident, and the pages print status text and incident identifiers. What a defender can use is the exact wording and the identifiers, so they are set out below. All Microsoft text in the second block is relayed; none was read in the admin center.

The first block holds the four strings the Microsoft 365 (Business or Enterprise) entry printed at 15:18 UTC, copied exactly from this site's read. A defender can use them as strings for a page change check on the public page, or to confirm that a message circulating during an outage matches what the page printed. That use is this site's suggestion.

Service degradation
Users may be unable to connect to multiple Microsoft 365 services
Last updated: Friday, November 13, 2026 at 2:56:52 PM UTC
Information about this issue is posted on this page because Microsoft 365 administrators may be unable to access the admin center to get Service health information.

The second block holds the incident identifiers and titles as relayed. A defender can search their own admin center, ticketing and mail flow logs for these identifiers. The EX1550543 title is printed by WindowsForum and by Chasms from a University of Pennsylvania extract. The MO1550821 and CR1550885 titles are printed by Chasms from the same extract. The saved relays print no title for TM1550488, and UC Today names PP1550869 without a title.

EX1550543 | Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods
MO1550821 | Users may be unable to connect to multiple Microsoft 365 services
CR1550885 | Agents may be unable to access Dynamics 365 Contact Center
TM1550488 | (no title printed in the saved relays)
PP1550869 | (named by UC Today, no title printed)

The third block holds what the two AI vendors' own status pages printed, copied from this site's reads. A defender who connects an AI assistant to a Microsoft 365 mailbox can compare these incident titles with the connector failures in their own logs.

OpenAI: Elevated errors affecting the Microsoft 365 connector
OpenAI: Investigating·Ongoing for 20 hours·Affects ChatGPT
Claude: Elevated errors affecting the Microsoft 365 connector (Nov 12, 2026)
Claude: Investigating - Nov 12, 2026 - 17:52 UTC
Claude: Identified - Nov 12, 2026 - 18:34 UTC
Claude: Update - Nov 12, 2026 - 20:28 UTC
Claude: Update - Nov 12, 2026 - 21:18 UTC
Claude: Update - Nov 12, 2026 - 22:23 UTC
Claude: Unresolved incident (still unresolved at 15:20:53 UTC on 13 Nov)

Hunting and hardening follow from the wording, not from any indicator: find which of your own alert paths run through the degraded service, find every integration that reads a mailbox, and check whether staff know where the public page is and what it will and will not tell them.

The question the record leaves open

When the explanation of an outage changes five times in a few hours, one of them a reversal, and the public status page prints none of them and no incident number, whose version is your incident report built on, and who in your organisation can tell the difference?

Key facts