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.
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
- 10:30 a.m. ETDowndetector reports begin climbing across Microsoft properties baseline is 29 reports
- 11:00 a.m. ETTeams-specific reports start easing partial recovery on the chat path
- 11:11 a.m. ETReports peak at 2,403, with SharePoint at 78 percent Excel 11 percent, Admin Center 6 percent
- 11:24 a.m. ETMicrosoft acknowledges on X, opens MO1437424 "investigating reports of issues"
- OngoingNo root cause published, no restoration ETA Service Health reads "service degradation"
- 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.
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 2026 | January 2026 | June 2026 (MO1329446) | |
|---|---|---|---|
| Primary symptom | SharePoint and file access | Exchange Online, sign-in | Opening files in Office for the web |
| Peak reports | 2,403 | Thousands | Not widely reported |
| Scope stated | Not disclosed | North America infrastructure | Subset of users |
| Root cause published | Not yet | Not during incident | Resolved, details in tenant |
| Duration | Ongoing at publication | Several hours | Hours |
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.
- 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.
- OfficialMicrosoft Service Health Status , the public dashboard that carried the "service degradation" classification
- OfficialMicrosoft 365 Status on X , the 11:24 a.m. ET acknowledgement and subsequent updates
- ReferenceMicrosoft Learn: SharePoint Online overview , documentation for the content layer that Teams files and Office for the web depend on
- ReportBleepingComputer: Microsoft 365 outage affects Teams, SharePoint and other services , incident ID and the peak complaint distribution
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.
