In a statement to TownLift, the county said several of its systems, including Microsoft Outlook and Teams, were disrupted. It warned residents and partners that email replies could be delayed that day and said it would post an update once service came back. County officials also said they had found no impact on other county services. Anyone who needed to reach a county department was asked to call while the outage continued.
The local story is only a few lines long, but it shows what happens when a government office runs its everyday communication through one cloud provider. When that provider has a bad day, the office has a bad day too.
What actually broke
The county's problem was one local piece of a much larger incident. BleepingComputer reported that in a Microsoft 365 admin center advisory tracked as MO1550821, Microsoft confirmed that customers may be unable to connect to multiple services, including Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot, and Microsoft Defender XDR. The same outlet noted that while the company initially reported Exchange Online connectivity problems in the Americas, it later confirmed that users in any region could be affected.
The Exchange side of the incident is also tracked under a second ID. Techaeris reported that the incident is tracked as EX1550543 in the Microsoft 365 admin center. IT support firm On-Site Technology listed both IDs and noted that a separate Teams incident, TM1550488, affected North America earlier on November 12, and Microsoft reported that one resolved. Admins should keep these separate. A green check on the morning Teams incident does not mean the afternoon Exchange-centered problem is fixed.
Pingoru, a third-party incident tracker that copies Microsoft 365 status posts, recorded the first Exchange Online notice at 6:10 p.m. UTC (11:10 a.m. in Utah). That notice said users might be unable to reach their mailboxes through several connection methods:
- Outlook on the web
- MAPI, the protocol desktop Outlook uses
- Exchange ActiveSync, used by many phone mail apps
- The REST API
That list matters. With Outlook desktop, web mail and phone mail all potentially affected, most users had no client they could switch to. Reinstalling Outlook or rebooting a laptop would not have helped.
By the numbers
CNBC reported that the outage began shortly before 1 p.m. and impacted Microsoft 365 services, Outlook and Teams. At the time, about 130,000 users reported issues with Outlook. Techaeris put the Downdetector timing more precisely: user reports began climbing at 12:39 p.m. ET on Downdetector, which logged those 128,874 Outlook complaints by 1:09 p.m. Those numbers are user-submitted reports. They are not a confirmed count of affected people or organizations.
Section summary: Microsoft is tracking the outage as MO1550821 and EX1550543. It started with Exchange Online mailbox access, spread to Teams, SharePoint, Copilot, Defender XDR and other services, and is separate from an earlier Teams incident (TM1550488) that Microsoft said was resolved.
Microsoft's explanation so far
Microsoft's status updates through the afternoon showed its theory of the problem changing several times:
- Elevated load. CNBC reported that Microsoft initially said infrastructure "elevated load across multiple regions" was responsible for the connectivity problems.
- Missing servers, not extra traffic. ABC News quoted Microsoft's later clarification: "We determined the elevated load isn't driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure."
- Failing health checks. Microsoft then said "our investigation indicates the failed health checks may originate from a specific component that's responsible for processing server health," according to ABC News.
- A partial fix. CNBC reported that at 4 p.m., Microsoft said it had "validated an alternative service health check method" that brought some affected servers back online.
Pingoru's copy of the status page shows how that played out:
- 12:16 p.m. Utah time: Microsoft had paused all deployments and configuration changes as a precaution.
- 2:01 p.m.: Microsoft said a review had found a small number of configuration updates it was investigating as possible contributors. That was a hypothesis, not a confirmed cause.
- 3:11 p.m.: Microsoft said its actions so far "have not provided the anticipated relief." It now said a core process on the affected servers was becoming overwhelmed, which made servers stop responding. Its next step was to fully isolate part of the infrastructure, restart components and bring traffic back gradually.
By then, the list of potentially affected services had grown to include:
- Planner and To Do
- Intune
- Defender for Office 365
- Several Purview services, including Data Loss Prevention and Communication Compliance
- Power BI exports of reports with sensitivity labels to PDF
- Parts of the Microsoft 365 Apps admin center
As of that 3:11 p.m. Utah update, the incident was still listed as ongoing, with the next update due at 11:30 p.m. UTC (4:30 p.m. in Utah). Microsoft had not published a confirmed root cause or a restoration time. The county had not said when its own service returned.
Section summary: Microsoft has moved from "too much load" to "too many servers dropping out" to "an overwhelmed core process." It has a partial workaround and some suspect configuration changes, but no confirmed root cause.
Is this a pattern?
Unfortunately, it looks like one. In January, TechRadar reported that Microsoft fixed a major outage that started January 22, 2026 and hit Outlook, Microsoft 365 and Teams. That incident was tracked as MO1221364 and blamed on a server capacity problem. The day before, Tom's Guide reported a separate incident in which Microsoft said a possible third-party networking issue may be affecting access to Microsoft 365 services, including Teams and Outlook for some users.
Each outage had a different cause. Still, three large Microsoft 365 messaging outages in one calendar year is enough to make any IT team rethink what "email is down" means for its own operations.
To be fair to Microsoft, this was not a total blackout. XDA Developers noted that there are also reports that some users are still able to access Teams. Summit County itself said only messaging was affected. Running Exchange servers on-site would not make an organization immune to outages either. It would just mean the outages were the organization's own to fix.
What admins and residents should do
For Summit County residents and partners: Call the county department you need while the outage continues. The county has not published an estimate of how long replies may be delayed. If a request is time-sensitive and you have already emailed it, confirm by phone.
For Microsoft 365 administrators:
- Check the admin center first. Look for MO1550821 and EX1550543 under Service health before spending time on user devices. The connection-method list above means local troubleshooting probably won't help.
- Don't mix up the incidents. TM1550488, the morning Teams incident, is reported resolved. Its status says nothing about the Exchange-centered outage.
- Review security and compliance tools. Defender for Office 365, Defender XDR and several Purview services are on the potentially affected list. After service returns, check whether any data loss prevention or compliance alerts were delayed during the outage.
- Hold off on rollbacks. Microsoft has paused its own deployments. If you have Intune or Microsoft 365 Apps cloud policy changes waiting, consider holding them until the incident is closed, so an outage symptom doesn't look like your change failed. This is general practice, not Microsoft guidance.
- Prepare an outage message. Summit County's short notice covered the basics: what was affected, what still worked, what people should do instead, and when the next update would come. Having a template ready before the next outage, with phone numbers that don't depend on Teams, is a good idea. This advice is based on general incident-response practice.
Bottom line: For Summit County, the outage meant slower email replies and more phone calls. For Microsoft, it is a multi-hour Microsoft 365 incident with a partial workaround and no confirmed cause. WindowsForum readers tracking Microsoft 365 service health or Exchange Online outages should watch for Microsoft's post-incident report, especially whether those configuration updates turn out to be the cause.
Correction (November 12, 2026): Two times in the Pingoru timeline were converted to Utah time with the wrong offset. Microsoft paused deployments at 19:16 UTC, which is 12:16 p.m. in Utah (MST), not 2:16 p.m.; and the update about configuration updates under investigation came at 21:01 UTC, which is 2:01 p.m. in Utah, not 3:01 p.m.