Microsoft's Outlook Outage and the 60,000 Exit Offers

Microsoft 365 went down on Thursday, November 12, 2026. Outlook, Teams, SharePoint and Copilot were all hit. As of 16:02 GMT on November 13, Microsoft’s advisory still read “Service degradation”, about 21 and a half hours after the start time the advisory lists. Downdetector’s count of Outlook problem reports peaked above 130,000, according to CIO.

I don’t know why it happened. I have no inside knowledge of Microsoft. Microsoft hasn’t published a root cause, and everything below is as of the advisory’s last update, stamped 16:02 GMT, so parts of it may be out of date by the time you read it.

Some coverage put the outage next to Microsoft’s voluntary exit offer to about 60,000 employees. Newsweek’s headline said it “Follows Plan to Cut Quarter of Workforce”, though the article under it describes a voluntary offer. I read the advisory text on November 13, through a public mirror. It says nothing about staffing, and the dates don’t support the link. It does show what recovery takes, which is worth thinking about before you offer exits at your own company.

The exit offer doesn’t fit the dates

CNBC reported that Microsoft said on Monday, October 26, that it was making a Voluntary Exit Offer, which chief people officer Amy Coleman described in a memo to employees. It covers certain workers in the U.S., Canada, India and the U.K., for employees at level 70 and below. CNBC’s unnamed source put the number eligible at about 60,000, roughly 27% of a 223,000-person workforce. That source also said Microsoft has no target for the program. It follows a 4,800-person layoff Microsoft announced in July. I wrote about the offer itself the day after it went out.

Employees decide in early December. The ones who accept leave on December 31. So nobody had left under this offer when the outage started.

Microsoft also expects most people to stay. A spokesperson told Fortune, “we anticipate an under 5% uptake on the 60,000 employees that are eligible for the program”. The same spokesperson said, “We don’t expect 60,000 people to walk out the door, and we would never want that.” Five percent of 60,000 is 3,000, so that’s under 3,000 people, if the spokesperson’s estimate holds.

KUOW reported that a spokesperson said AI is not driving the buyout programs. That’s a stated reason, and stated reasons moved a lot in 2026. KUOW also reported that the sales organization, some corporate services such as marketing, and some engineering teams aren’t participating. The heads of each organization decided who was eligible.

The dates rule out departures under this offer. People did leave Microsoft earlier this year, through the July layoff and a spring retirement offer that Fortune says about 30% of eligible staff took. Nothing I read says those cuts, the buyout or AI played any part in the outage.

What the advisory shows

The incident is MO1550821, per BleepingComputer. Microsoft’s advisory sits in the Microsoft 365 admin center, behind a login. I read its text through a public mirror at Cloud Admin Hub. It’s titled “Users may be unable to connect to multiple Microsoft 365 services” and starts at 18:26 GMT on November 12, which is 1:26 PM Eastern. It names Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Microsoft Defender XDR, and it carries more than 30 timestamped updates.

All times below are GMT.

At 18:27, Microsoft said affected infrastructure was under elevated load across multiple regions. By 18:58 it had redistributed connection traffic worldwide and was restarting affected servers.

At 19:30, Microsoft said it had paused all deployments and configuration changes while it reviewed recent changes. The same update said “the elevated load isn’t driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable”.

Thirteen minutes later, at 19:43, it said “affected servers are failing automated health checks, which is causing them to become unavailable”. That update also said the problem may be related to a recent change to a component involved in processing those checks. Fifteen minutes later it said it hadn’t identified any recent changes that correlate with the start of impact.

So servers were failing health checks and dropping out, and the load landed on the ones still up. The advisory doesn’t say whether the checks were wrong or the servers were sick.

From there the advisory reads as one hypothesis after another:

• From 19:58 to 20:38, engineers tested a targeted change to bypass a component. Many affected servers had become unresponsive, which blocked validating it.
• At 20:57, an alternative health check method was validated on a subset of infrastructure.
• At 22:03, it said a core process on the affected servers was becoming overwhelmed.
• At 00:00 on November 13, it said restored servers “can become unresponsive again once they begin receiving traffic”. It was analyzing diagnostic data with networking and platform experts.
• At 01:12, it said the process responsible for establishing secure connections becomes overwhelmed, so the servers stop processing requests. In the same update: “we’ve begun reverting a recent network configuration change that correlates with the start of impact”.
• At 02:58, Microsoft said it had monitored the changes applied to improve serviceability and confirmed one was not taking as expected. It didn’t say which change. At 04:56 it reported a surge in outbound call volume from routing services to backend servers after mitigation actions.
• At 06:54, it said it had observed marginal success.
• At 07:24, it reported positive server stability after patching an upstream authentication and routing configuration on part of the infrastructure.
• From 11:01 to 12:59, recovery went region by region. By 14:01 email queues were nearing normal.

“Correlates with” is Microsoft’s phrase at 01:12. It didn’t say the network change caused the outage. The advisory also repeats that there’s no evidence of malicious activity, and that a full post-incident report will follow. It describes engineers testing changes on subsets, reverting changes and restarting servers, and says nothing about whether AI was used in the recovery.

What that work needs

Each step in that list needed a person who knew something specific: what had shipped recently, what the health check component touches, whether a bypass was safe to try on a subset, and what a correlation is worth when you’re deciding to revert.

I’d expect very little of that to be written down in full, at Microsoft or anywhere else. Most of it sits with the people who built the system and run it.

I think that’s the work an exit offer puts at risk. I can’t tell you whether it’s at risk at Microsoft. KUOW reported that some engineering teams aren’t in the offer, and I don’t know which ones.

What a smaller company should take from it

If you’re thinking about an exit offer, or a cut you plan to justify with AI, do this before you announce anything.

For each system you run, write down who you would page at hour fifteen of a bad outage. I mean the person who knows why the system is built the way it is, who may not be on the on-call rotation. Then check whether what that person knows is written down anywhere a stranger could use it. If it isn’t, the cut or the offer is a bet that the person stays, or that you’ll find a replacement who can learn it faster than the next outage arrives.

Do this before a cut is on the table. I’d expect people to share less once they think the list is step one of a layoff, which is part of why I build around trust.

When I wrote about the offer, I said a voluntary exit loses the people with the best outside options first. I’d expect some of them to be on your hour-fifteen list. That’s my opinion, and I don’t have Microsoft’s numbers on who is taking it.

If the plan is to cut junior people and do more with AI, ask who is learning those systems now. The path to senior ran through grunt work that AI now does, and I think the people on your list got there that way.

Watch for the post-incident report

Microsoft says a full post-incident report will follow. When it comes, I’d look for the timeline of when each cause was identified, which is what analyst Sanchit Vir Gogia of Greyhound Research said customers would want, per CIO. I’d also look for what it says about the health check component and the network change.

BleepingComputer also notes an earlier Teams incident the same morning, TM1550488, that Microsoft says was resolved. Microsoft hasn’t said whether the two are related.

If you run a startup and want help working out which systems depend on which people before you change headcount, that’s part of the fractional CTO work on my consulting page.