Microsoft rolls back change after SharePoint pages go blank
Reviewed by Helen Jones
On 16 September 2026, from about 1604 to 1730 GMT, a Microsoft configuration change that controls how servers deliver code to render SharePoint Online pages left some users unable to open sites or pages. Affected people saw the error "Sorry, something went wrong: Thread was being aborted." Microsoft tracked the event as incident SP1472983, reverted the change, and said service telemetry showed the problem cleared. Impact was partial, not every tenant, and lasted roughly an hour and a half. The company said it is reviewing how it validates and deploys configuration changes. A preliminary post-incident report was expected within two business days and a final report within five.
Before this, many small admin teams still treated blank SharePoint pages as a local problem first: permissions, browser cache, custom scripts, or a broken web part. That habit burns time when the failure is upstream and the only real fix is Microsoft rolling back its own change. What changed is a clear reminder that page delivery itself can fail for about 90 minutes with no tenant-side switch to flip. For teams that run the company intranet, hub navigation, and Teams-linked sites on SharePoint Online, that window is when support queues fill with "the site is down" tickets while you wait on the service health story and the post-incident write-up.
Analysis
This is a trap to avoid, not a reason to rebuild sites or chase phantom permission fixes. Draft a one-page blank-page runbook now: check Microsoft 365 service health for SharePoint incidents first, send a short holding message to users, and list the admin actions you will not take during a global render failure.
Source note
Pulse published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "Microsoft rolls back change after SharePoint pages go blank", Collab365 Spaces. 2 sources referenced.