Microsoft Outage Cut Contact Center Agents Off for Nearly Eight Hours

Dynamics 365 Contact Center went dark for just under eight hours on Thursday evening, locking agents out of their workspace and halting voice and messaging traffic. Microsoft restored agent access at 00:57 GMT on Friday. The wider Microsoft 365 outage, however, was still running more than 13 hours after Exchange Online first failed, with no recovery time given.

The contact center failure carries incident number CR1550885. Microsoft logged it as a Dynamics 365 Apps incident that began at 17:00 GMT on November 12. It is a separate ticket from the Exchange Online and Microsoft 365 incidents opened the same afternoon. Microsoft also assigned it a different preliminary cause.

What caused the contact center failure?

Microsoft service health stated in incident CR1550885, dated November 13, 2026: "A portion of the database infrastructure responsible for Contact Center experienced connectivity failures."

The impact split into two failure modes. Agents who could not sign in could not send or receive messages or voice calls at all. Agents who did get in saw degraded voice and messaging performance rather than a clean failure.

The remediation path ran through infrastructure failover. Microsoft failed over the affected database infrastructure and later reported that access, voice and messaging had returned. Transcripts remained intermittent after that step. Microsoft then performed a transcript-service restart, entered a period of monitoring, and only then declared the service restored at 00:57 GMT on Friday.

What is the state of the wider Microsoft 365 outage?

The companion failure started earlier and remained open. Exchange Online incident EX1550543 began at 16:17 GMT on November 12, leaving users unable to reach Exchange Online mailboxes. Microsoft opened a wider Microsoft 365 incident, MO1550821, at 18:26 GMT to track the broader impact.

As of the 05:43 GMT update on Friday, both incidents remained in service degradation. Microsoft scheduled its next update for 07:00 GMT. It gave no estimated recovery time. Microsoft's public status page still showed a Microsoft 365 degradation and no Azure issues. The @MSFT365Status account last posted at 05:01 GMT.

Microsoft service health stated at 05:43 GMT on November 13, 2026, under incidents EX1550543 and MO1550821: "As of now, we are not aware of any malicious activity that is causing this incident. We will continue to treat this incident with urgency and priority until full resolution."

What did Microsoft say caused the Microsoft 365 failure?

Microsoft's earlier technical explanation pointed to a secure-connection process under strain. The company said a process on affected servers "responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests." That statement identified connection-establishment overload as the proximate mechanism.

Microsoft also linked the start of impact to a configuration change. The company said it had begun reverting "a recent network configuration change that correlates with the start of impact." That reversion work was underway before the 05:43 GMT update.

Later updates complicated the picture. Microsoft described mitigation work that produced traffic surges during the recovery attempt. It also reported machines "stuck in a bad state," indicating that rollback alone did not clear the failure.

What should contact center and IT operations teams take from the timeline?

The incident set spans three separate tickets with distinct causes, start times and statuses:

• CR1550885 — Dynamics 365 Contact Center, began 17:00 GMT November 12, database infrastructure connectivity failures, restored 00:57 GMT November 13.
• EX1550543 — Exchange Online, began 16:17 GMT November 12, mailbox access failure, still degraded at 05:43 GMT Friday.
• MO1550821 — Microsoft 365 wider impact, opened 18:26 GMT November 12, still degraded with no recovery estimate.

Contact center operations bore a distinct failure mode from the mail platform. The Dynamics 365 ticket cited database infrastructure connectivity, while the Microsoft 365 tickets cited a secure-connection process overwhelmed after a network configuration change. Teams running both workloads faced two separate remediation timelines from a single vendor on a single evening.

The transcript subsystem lagged the rest of the recovery. Access, voice and messaging returned before transcripts stabilized, and Microsoft needed a dedicated transcript-service restart plus a monitoring period before it could declare the Contact Center incident closed. Organizations that depend on transcript records for compliance or quality assurance should note that this layer recovered last.