Blog

When the access path is down and the suite still answers

2026-10-26

On 13 October 2026 Microsoft 365 issue MO1505952 ran from 07:40 to 18:31 UTC for users on Global Secure Access. The disable-GSA line landed at 17:56 UTC. The final scope says Germany. Mid-incident reports also named the UK.

At 17:56 UTC on 13 October 2026, a West Europe tenant's Microsoft 365 service health for MO1505952 gained one sentence: users may disable Global Secure Access to reach the affected services until the incident is resolved. The final block on that same item puts the start at 07:40 UTC and the end at 18:31 UTC. The bypass showed up 10 hours and 16 minutes after that start, and 35 minutes before that end.

What the retained message says

The mirror is a West Europe tenant's service health, not a press release. Times below are converted from the CEST stamps on that page (UTC+2 on 13 October). The final block itself was posted at 18:54 UTC. It says users may have been unable to access multiple Microsoft 365 services using Global Secure Access. The service list is Outlook, Outlook on the web, OneDrive, SharePoint Online, Microsoft Teams, and Windows 365 Cloud PCs. Scope of impact: some users in Germany who tried to reach those services using GSA. Start Tuesday 13 October 2026 at 7:40 AM UTC. End 6:31 PM UTC. Root cause line: a section of GSA infrastructure was performing below acceptable performance thresholds. Final status: restarts completed, confirmed through telemetry and user reports.

The update list on that mirror, in UTC:

• 09:41: reviewing telemetry to isolate the source. This is the earliest post on the mirror, 2 hours and 1 minute after the start time the final block uses.
• 11:30: identified. A section of GSA infrastructure is performing below acceptable performance thresholds. They are applying performance and traffic optimizations.
• 13:29: still applying those optimizations, with early signals of recovery.
• 14:35: optimizations deployed. Errors dropped at first. The same sentence says this did not fully resolve the issue.
• 14:57: redirecting traffic off the underperforming infrastructure.
• 15:21: redirect to healthy infrastructure complete. Still looking for more mitigations.
• 16:22: restarting the portion that had traffic removed. Internal tests show this fixes impact for some users.
• 17:23: targeted restarts continuing. Telemetry on the restarted parts looks healthy. Some users confirm resolution.
• 17:56: workaround. Users may disable GSA to access the affected Microsoft 365 services until the incident is resolved.
• 18:18: finishing restarts. They expect all impact resolved by 19:00 UTC. Telemetry is showing recovery.
• 18:54: the final block above. End time written as 18:31 UTC.

IncidentHub's recording of status.cloud.microsoft the same day has the same shape, with clocks a few minutes off this tenant list. The exception worth naming: they record the workaround line at 18:20 UTC, not 17:56. Quote the tenant sentence at 17:56. Do not average the two clocks into a third time nobody wrote.

The morning notice named the UK

The retained final block names Germany only. That is not what the notice said at lunch. Neowin at 12:51 UTC, as written up by WindowsForum (published 13:07 UTC), described Microsoft's announcement as Germany and the United Kingdom, the same service list, and a section of GSA infrastructure already found. WindowsForum also wrote, at that hour, that Microsoft had not published turning GSA off. IncidentHub says the updates it recorded named Germany and the UK until 17:26 UTC, and that those updates stated the start as 08:00 UTC. At 17:26 the scope narrowed to Germany only and the start moved to 07:40.

A note that copies only the final block will say Germany, from 07:40, for 10 hours and 51 minutes. A helpdesk that worked the morning in London was working a country that block does not name, against a start time 20 minutes later than the page had been saying. Keep the lunch scope and the retained scope. They are two records of the same incident. They are not the same sentence.

The suite can answer while the path does not

Global Secure Access is the network path in front of the apps, for tenants that turn it on. Microsoft's operations doc for the Microsoft traffic profile is the product description: that profile carries Microsoft 365 traffic through GSA. Every scope line on MO1505952 is users using GSA. The updates do not say Outlook was down for someone who never sent mail through that profile.

That split is the whole incident. A successful open of Outlook on a network that does not use GSA answers a different question than a Munich laptop whose Microsoft traffic profile is pointed at the section Microsoft called under threshold. At 14:35 they had already said the first optimization cut errors and did not fix it. Retrying the same path after that sentence is how the afternoon disappears.

Copy you can adapt

The weak version, which could be pasted onto any afternoon:

Microsoft 365 is down for Outlook, Teams, and OneDrive in Europe. We are investigating with our provider. Please retry, and reset your password if sign-in fails.

That paragraph costs the country, the path, and the clock. A user in Chicago who is not on GSA files a password ticket for a failure the scope line never included. A user in Munich on the Microsoft traffic profile waits, because disable GSA does not exist on the item until 17:56 UTC. A UK site lead reads the final block the next morning, sees Germany only, and closes the London tickets as unrelated. The 14:35 update had already said the error drop was not a fix. "Please retry" after that line repeats the instruction that failed.

Three notes that keep the path and the clocks:

13:10 UTC, 13 October. MO1505952, on our West Europe service health: users reaching Microsoft 365 through Global Secure Access may be unable to use Outlook, Outlook on the web, OneDrive, SharePoint Online, Teams, and Windows 365 Cloud PCs. At 11:30 UTC Microsoft wrote that a section of GSA infrastructure is below performance thresholds and that they are applying traffic optimizations. Reports of the notice at 12:51 UTC name Germany and the United Kingdom. As of 13:07 UTC that notice had not posted a workaround, including turning GSA off. Users who do not use GSA are outside this scope. Opening Outlook on a network that does not use GSA does not clear it.

18:00 UTC. At 17:56 UTC MO1505952 added a workaround: users may disable GSA to reach the affected services until this incident resolves. That bypasses the path. It does not say Exchange or Teams recovered for people who stay on GSA. The 14:35 UTC update already said the first traffic optimization cut errors and did not fix the issue. Mail stays failed on this page for profiles that must stay on GSA.

19:05 UTC. MO1505952 final status at 18:54 UTC says resolved. End time on the message is 18:31 UTC. Start time is 07:40 UTC. Scope is some users in Germany using GSA. Root cause line: a section of GSA infrastructure was below acceptable performance thresholds. This retained scope does not name the United Kingdom. Our 13:10 note did, because that is what reports of the notice said at 12:51 UTC. IncidentHub's recording of the status page says the UK stayed listed until 17:26 UTC, when the start time also moved from 08:00 UTC to 07:40 UTC. Both clocks stay in the timeline.

A reader who was not on the bridge can check each sentence against the tenant item, Neowin's 12:51 report, and IncidentHub's timeline. The weak paragraph cannot be checked, so it cannot be trusted an hour later.

What not to do

• Do not call the suite down for users who are not on GSA. The scope line is the path.
• Do not tell people to disable GSA before that workaround is on the item. On this mirror the sentence is 17:56 UTC. At 13:07 it was not there.
• Do not replace the lunch scope with the final scope. Germany only is the retained line. The UK was on the mid-incident notice.
• Do not treat the 14:35 error drop as recovery. The same update says it did not fully resolve.
• Do not close the incident because a public Microsoft host answered. That host did not take the GSA path.

Operator checklist

1. Write the issue ID on the note. This one is MO1505952.
2. Write the path, then the apps. GSA, then Outlook, Teams, OneDrive, SharePoint, Windows 365.
3. Keep the scope sentence that was true when you wrote, and the scope sentence the final block keeps.
4. When a mitigation update says errors fell and the issue remains, copy both halves.
5. Put the workaround clock on the page. Here, disable GSA at 17:56 UTC, end written as 18:31 UTC.

StackWitness does not publish a Microsoft 365 or Global Secure Access page, so this post has no probe result for MO1505952. The index at /status is host reachability next to a vendor feed. Open /status/cloudflare if you want to see the two columns on a host we do measure. Reachable means that host answered from our regions. It does not mean a customer's GSA profile can reach Exchange, and a host that answered does not clear an incident scoped to that profile. The path name, the country line, and the 17:56 workaround still come from service health. Copy those clocks. The final block is the last of them, not the only one.