Microsoft 365 started failing for thousands of users this morning, and the complaint data points at one service rather than the ones people are naming. Reports began climbing just after 10:30 a.m. ET on July 23, peaked at 2,403 on Downdetector by 11:11 a.m. against a normal baseline of 29, and Microsoft acknowledged the incident on X at 11:24 a.m. with the line "We're investigating reports of issues with Microsoft 365 services." The company is tracking it as MO1437424 in the admin center. Here is the part most coverage skips: SharePoint accounts for 78 percent of the complaints. Teams is what everybody noticed, but SharePoint is where the failure appears to live.

  • Timing: first reports just after 10:30 a.m. ET, peak of 2,403 Downdetector reports at 11:11 a.m., Microsoft's public acknowledgement at 11:24 a.m.
  • Complaint split: SharePoint 78 percent, Excel 11 percent, Microsoft 365 Admin Center 6 percent. That distribution describes a content and file layer problem, not a chat problem.
  • Status: Microsoft's Service Health page classified it as "service degradation" and has published no root cause. Teams reports were already easing around 11:00 a.m.
  • Do not misread the noise: Downdetector simultaneously showed spikes for AWS, Cloudflare, OpenAI, Dropbox and Fortnite. That is a reporting artifact, not evidence of one shared failure.
Microsoft 365 service dependency stack Teams files, Office for the web and the admin center all read and write through the SharePoint content layer, so a fault there surfaces as three separate app outages. WHAT USERS SEE vs WHERE IT BREAKS Teams files, tabs, attachments Office for the web Excel, Word, PowerPoint Admin Center health, config, reports SharePoint Online content layer 78% of today's complaints land here Identity, routing and service fabric genztech.blog
Fig 1 Teams, Office for the web and the admin center are all SharePoint clients. One content-layer fault presents as three unrelated app outages, which is why the user-facing symptom and the actual failure point rarely match.

What actually broke, and when?

The sequence is unusually well documented for an incident still in progress. Downdetector reports for Microsoft services started rising just after 10:30 a.m. ET. By 11:11 a.m. the counter hit 2,403, roughly 83 times the normal baseline of 29 reports. Microsoft posted its first public acknowledgement at 11:24 a.m. ET, nearly an hour after the first user reports, and pointed administrators to incident MO1437424 for detail that is only visible inside the tenant admin center. The public Service Health Status page carried the softer label "service degradation" rather than a full outage.

RelatedThe Teen Suing Meta Over Addiction Just Dropped the Case

  1. 10:30 a.m. ETDowndetector reports begin climbing across Microsoft properties baseline is 29 reports
  2. 11:00 a.m. ETTeams-specific reports start easing partial recovery on the chat path
  3. 11:11 a.m. ETReports peak at 2,403, with SharePoint at 78 percent Excel 11 percent, Admin Center 6 percent
  4. 11:24 a.m. ETMicrosoft acknowledges on X, opens MO1437424 "investigating reports of issues"
  5. OngoingNo root cause published, no restoration ETA Service Health reads "service degradation"
  6. NextPost-incident report lands in the admin center under MO1437424 typically days later, tenant-only

Beyond the core three, Downdetector logged complaints against Outlook, OneDrive, Copilot, Azure, Xbox Live and the Microsoft Store. Some users also reported trouble downloading Windows updates and installing Office desktop apps, which is a delivery and licensing path rather than a document path.

Why does SharePoint take 78 percent of the complaints?

Because it is not really three outages. SharePoint Online is not just the intranet product with the site templates nobody likes. It is the storage and content substrate underneath a large share of Microsoft 365. When you drop a file into a Teams channel, that file lives in a SharePoint document library. When you open a spreadsheet in Excel for the web, the document is fetched and locked through the same content stack. OneDrive for Business is the same platform wearing a personal-storage label.

So a fault in that layer radiates outward. Chat messages keep flowing because they run on a different pipeline, which is exactly why Teams reports were already tapering by 11:00 a.m. while SharePoint stayed pinned. Meanwhile file tabs fail to load, attachments hang, and Excel for the web throws errors. To a user, three products broke. To the platform, one dependency did.

Downdetector complaint distribution at the 11:11 a.m. ET peak SharePoint accounted for 78 percent of complaints, Excel 11 percent, the Microsoft 365 Admin Center 6 percent, and all other services about 5 percent. COMPLAINT SHARE AT PEAK · 2,403 REPORTS · 11:11 A.M. ET SharePoint 78% Excel 11% Admin Center 6% Everything else 5% Baseline before the incident: 29 reports total genztech.blog
Fig 2 · data Complaint share at the 11:11 a.m. ET peak. A distribution this lopsided is diagnostic: it says one dependency failed and its clients reported separately, rather than a broad platform-wide fault.

Why did Downdetector light up for AWS and Cloudflare too?

Because Downdetector measures people complaining, not infrastructure failing. Around the same window it showed elevated reports for Amazon Web Services, Cloudflare, OpenAI, Dropbox and Fortnite. Every widespread Microsoft 365 incident produces this pattern. A user whose work stops loading does not know which vendor failed, so they report against whatever service they were touching, or against the biggest name they can think of. Aggregators then show a wall of red that reads like a coordinated internet failure.

Treat correlated Downdetector spikes as a signal of user attention, not a signal of shared root cause. Nothing published so far ties this incident to any non-Microsoft provider, and Microsoft has not attributed it to an upstream dependency. If you are drafting an internal status note today, that distinction is the difference between an accurate update and an alarming one.

How does this compare with Microsoft's recent outages?

 Today, July 23 2026January 2026June 2026 (MO1329446)
Primary symptomSharePoint and file accessExchange Online, sign-inOpening files in Office for the web
Peak reports2,403ThousandsNot widely reported
Scope statedNot disclosedNorth America infrastructureSubset of users
Root cause publishedNot yetNot during incidentResolved, details in tenant
DurationOngoing at publicationSeveral hoursHours

The pattern across all three is the same and it is the real story: Microsoft acknowledges quickly in vague public language, routes the substance to a tenant-only incident ID, and publishes the actual post-incident review where only administrators can read it. For a platform this systemically important, the public record of why it failed stays thin.

Who is actually affected?

Anyone whose workday routes through a document library, which in most enterprises means nearly everyone. Concretely: shared file access in Teams channels, co-authoring in Excel and Word for the web, OneDrive for Business sync, SharePoint-backed intranets and Power Platform apps that read from lists. Pure chat, voice and meeting traffic in Teams looks comparatively healthy, which matches the reports easing by 11:00 a.m.

RelatedBrave Origin: A Paid Browser That Strips Out Crypto and AI

The practical guidance while this is live is unglamorous. Work from locally synced or downloaded copies rather than fighting the web clients, and hold off on bulk uploads or migrations, because writes into a degraded content layer are where partial-state corruption and duplicate-file messes actually come from. Administrators should read MO1437424 in the admin center rather than trusting the public status page, which historically lags and understates.

What it means for the market

Microsoft (NASDAQ: MSFT) has absorbed outages of this size without a durable share reaction, and there is no reason to expect a different pattern from a partial-day degradation with no data-loss claim. The signal for investors is not the stock print today. It is the accumulating enterprise-risk argument: Microsoft 365 now concentrates chat, documents, identity and increasingly Copilot into one blast radius, and every incident where a single content layer takes down three visible products strengthens the case procurement teams make for multi-vendor collaboration stacks. Watch whether this becomes a repeat SharePoint-layer incident. Recurrence in the same subsystem is what moves renewal negotiations and pulls regulatory attention in Europe, and that is a slower and more consequential channel than a one-day chart move.

What to watch · next 72 hours
  • The root cause language. If MO1437424 lands on a "recent service change" that was reverted, this joins a long run of Microsoft outages caused by its own deployments rather than by hardware or upstream providers.
  • Whether writes were affected. Read failures are an annoyance. If uploads or co-authoring saves silently failed, expect version-history cleanup work in affected tenants.
  • Recurrence in the content layer. A second SharePoint-rooted incident inside a quarter changes this from bad luck into a reliability trend worth raising at renewal.
  • Public disclosure depth. Watch whether Microsoft publishes anything outside the admin center. So far the substance stays behind the tenant wall.

Our take

The interesting thing here is not that Microsoft 365 went down, because at this scale something is always degraded somewhere. It is that the complaint distribution diagnosed the incident faster and more precisely than the vendor's own public communication did. Downdetector said "SharePoint, 78 percent" at 11:11 a.m. Microsoft said "issues with Microsoft 365 services" at 11:24 a.m. One of those tells an administrator where to look.

That gap is a choice, not a technical limitation. Microsoft knows which subsystem is unhealthy well before it posts, and routing the specifics to a tenant-only incident ID keeps the public record vague while satisfying the contractual obligation. The fix is not complicated: name the affected subsystem in the public status post. Until that changes, the fastest read on a Microsoft outage will keep coming from crowdsourced complaint ratios rather than from the company running the platform.

Primary sources

Original analysis by GenZTech. Reported live on July 23, 2026 while the incident was ongoing. Figures from Downdetector at the 11:11 a.m. ET peak, via BleepingComputer.