The Status page is not working well, but I managed to subscribe to their RSS feed and it has been sending out updates periodically. I'll post some of them here.

9:02 PM UTC: We've validated an alternative health check method on a subset of affected infrastructure, which allowed the servers in that subset to successfully return to service, and we're now applying this change more broadly. We're also preparing an automated recovery process to continually detect and restart unresponsive servers, to help keep them in service while this change progresses. Additionally, our review of recent changes has identified a small number of configuration updates that we're investigating as potential contributors to the issue.

Previous status: While validating the targeted change, we found that many of the affected servers have become unresponsive, which is preventing us from confirming whether the change is effective. We're restarting these servers so they can come back online with the change in place, and we're applying the same approach to additional affected portions of our infrastructure to validate the results more broadly.

8:52 PM UTC: While validating the targeted change, we found that many of the affected servers have become unresponsive, which is preventing us from confirming whether the change is effective. We're restarting these servers so they can come back online with the change in place, and we're applying the same approach to additional affected portions of our infrastructure to validate the results more broadly.

Previous Status: While we haven't identified any recent changes that correlate with the start of impact, our investigation indicates the failed health checks may originate from a specific component on the affected servers that's responsible for processing them. We're deploying a targeted change to bypass this component on a subset of servers to validate whether this restores availability, and we've taken steps to prevent additional servers from being removed from service while we work to return the affected servers to service. We're also investigating why affected servers are experiencing elevated processor usage while handling requests.

7:52 PM UTC: We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service.

7:30 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure. We're investigating what's causing these servers to become unavailable while we work to safely return them to service.

7:16 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've also moved traffic for some services off the affected infrastructure to further reduce load, with additional traffic moves in progress.

6:59 PM UTC: We've completed redistributing connection traffic across our worldwide infrastructure, and we're moving additional traffic off the affected infrastructure to further reduce load. We're also restarting affected servers to return them to service. In parallel, we're investigating whether the elevated traffic reflects a genuine increase in requests or a shift in how traffic is being routed across our infrastructure.

From the 10:11:39 PM UTC update:

Current status: We're continuing to pursue all available pathways to restore service, as our actions taken thus far have not provided the anticipated relief. Our investigation has found that a core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss.

To validate a potential recovery approach, we're fully isolating a portion of our service infrastructure, restarting the affected components, and gradually reintroducing traffic to confirm our services remain stable before applying this approach more broadly. We're also analyzing traffic patterns across our entire service infrastructure and evaluating whether isolating traffic within each region may allow affected regions to recover independently.

From the 9:41:46 PM UTC update:

Current status: We're continuing to work through restarting and validating the affected servers to safely return them to service, and we're exploring opportunities to expedite this process. In parallel, we're assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery.

From the 9:01:14 PM UTC update:

Current status: We've validated an alternative health check method on a subset of affected infrastructure, which allowed the servers in that subset to successfully return to service, and we're now applying this change more broadly. We're also preparing an automated recovery process to continually detect and restart unresponsive servers, to help keep them in service while this change progresses. Additionally, our review of recent changes has identified a small number of configuration updates that we're investigating as potential contributors to the issue.

From the 8:44 PM UTC update:

Current status: While validating the targeted change, we found that many of the affected servers have become unresponsive, which is preventing us from confirming whether the change is effective. We're restarting these servers so they can come back online with the change in place, and we're applying the same approach to additional affected portions of our infrastructure to validate the results more broadly.

Previous Status: While we haven't identified any recent changes that correlate with the start of impact, our investigation indicates the failed health checks may originate from a specific component on the affected servers that's responsible for processing them. We're deploying a targeted change to bypass this component on a subset of servers to validate whether this restores availability, and we've taken steps to prevent additional servers from being removed from service while we work to return the affected servers to service. We're also investigating why affected servers are experiencing elevated processor usage while handling requests.

From the 11:06:31 PM UTC update:

Current status: We've begun returning a portion of the affected servers to service, and they're remaining stable so far. We've also shifted traffic and connections to alternative pathways wherever possible and have observed limited recovery in some regions.

We've streamlined our recovery process to expedite returning the remaining affected servers to service. To further support recovery, we're implementing protective traffic management measures in a specific location to reduce load on the affected infrastructure, and we'll expand these measures to additional locations if we observe positive results. As capacity is restored, users may experience a gradual recovery as their clients reconnect to the service.

Reddit-level speculation.

I feel for those stuck in there. The outage going on for this long has got to be fucking brutal.

In retrospect, the cause and cure are obvious to everyone.

Plenty of internal accounts from previous employees highlight this.

Most of the time we get demonized by resume-driven developers job-hopping every few years (seems like the lack of deep expertise is working out). Today we get to laugh at their expense. These problems were entirely foreseeable and avoidable.

They still don't know why this "core process" is maxing out the processor for no reason.

Site was taken offline, war rooms ensued. 48 hours later, an Ops team from Redmond was flown out. Another three days and they determined it was several legacy servers were going down and the load balancing servers were getting hit so hard, they also failed. It was a cascading effect that killed everything.

CIO was pissed. The company got absolutely lit up on every social media channel for their ineptitude. The CIO vowed it would never happen again, they were upgrading the entire network and infrastructure to avoid it happening again. Fast forward six months to the next major release. Same thing, same panic, same cascading failures because servers were collapsing under the traffic to the website. Another war room, another Ops team flies out. Two days later they figured out it was some buggy code that was causing it.

This after 8 rounds of load balancing testing to the tune of 10X the amount of traffic the site sees on these major release dates without so much as a hiccup.

I left two months later, but the overall feeling was the same - total amateur hour from Microsoft after our company was gifted major discounts to go all in with their hardware & network gear. The company found out the hard way it wasn't a smart decision.

The scary part was this some 20 years ago - seems like not much has changed considering how frequently Github is down now too.

Actual tech write-ups can come later.

I'm sure it's more complicated than that.... but from my POV, which is extremely limited and informed by what others online tell me.... that this is amateur hour

What would it take for it to be professional hour?

You know a lot of talented people who work there also post here, and it's not fair to insinuate that they aren't talented because some vastly complex system somewhere in the world had a bad day.

Stuff happens, things break. That's why lots of nines cost a lot of money. It doesn't automatically mean that anyone is incompetent.

lots of nines means not having significant downtime. we passed 99.99% hours ago, and we're on the way to 99.9%

Almost certainly not the fault of individual people, it's a management failure of course

I agree there are many talented people at Microsoft, but I don’t see the professionalism in this incident.

Put another way, if they didn’t turn it off and on again, I would think less of them because that’s the first thing you should always do unless you know better

we "bounce" the servers when on calls with customers.

Everyone has occasional outages but this is the worst 365 outage our org has seen since starting with M365 in 2019.

"We're also preparing an automated recovery process to continually detect and restart unresponsive servers, to help keep them in service while this change progresses."

https://www.abc.net.au/news/2026-11-13/microsoft-outage-affe...

From the 11:06:31 PM UTC update:

Current status: We've begun returning a portion of the affected servers to service, and they're remaining stable so far. We've also shifted traffic and connections to alternative pathways wherever possible and have observed limited recovery in some regions.

We've streamlined our recovery process to expedite returning the remaining affected servers to service. To further support recovery, we're implementing protective traffic management measures in a specific location to reduce load on the affected infrastructure, and we'll expand these measures to additional locations if we observe positive results. As capacity is restored, users may experience a gradual recovery as their clients reconnect to the service.

---

The 10:11:39 PM UTC update is a little chilling. They don't know why what's happening is happening so they're doing experiments.

I do that with closed-source software when I don't want to bother trying reverse engineer it, but these guys have the code! Yikes.

I recognize that even w/ the code available there are likely behaviors that aren't likely to be anticipated because of the scale of traffic. Complex systems fail in complex and non-intuitive ways.

From the 10:11:39 PM UTC update:

Current status: We're continuing to pursue all available pathways to restore service, as our actions taken thus far have not provided the anticipated relief. Our investigation has found that a core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss.

To validate a potential recovery approach, we're fully isolating a portion of our service infrastructure, restarting the affected components, and gradually reintroducing traffic to confirm our services remain stable before applying this approach more broadly. We're also analyzing traffic patterns across our entire service infrastructure and evaluating whether isolating traffic within each region may allow affected regions to recover independently.

I mean it sort of does if you know the whole system inside and out and have the ability to reason about it, but just having the code for each component doesn't by itself solve the real problem of understanding

But maybe don't understand it because they didn't write it themselves?

2. Art imitates Life

3. Goto 1

https://youtu.be/3TNpOD6bov8

> Current status: We’re continuing to pursue all available pathways to restore service, as our actions taken thus far have not provided the anticipated relief. Our investigation has found that a core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss.

For reasons that I cannot fathom, Microsoft wants to act as the relay to my self-hosted e-mail account, if I add the account in Outlook.

I can conjecture some reasons. Datamining would be high on the list, since MS can read your mail and thus market to you more effectively. Governments might also be happier if MS can provide them with one-stop access (like Prism) to otherwise self-hosted e-mail accounts proxied through a central server.

I'm being an ass in saying this, because I'm aware human motivation is a beautiful kaleidoscope of variables, but I would have guessed at the venn diagram of 'those willing to compromise and use a Microsoft product' is mutually exclusive with that of the 'I'm hardcore enough to self-host email'.

I will say, however, that Outlook used to be one of the better desktop email programs, so I'll grant some legacy lenience.

I use Gmail's web interface for my Gmail account (which, I'll admit, makes my little rant above more than a little hypocritical)

And in my self hosted email setup I use RoundCube (web interface).

Na, that would simply be the kaleidoscope part you mentioned, wouldn't it? For what it's worth, I found the combination just as peculiar as you did.

One of GitHub's services will be down again by next week.

DDOS?

First, you have every client retrying connections, whether automated or manual retries. This generates extra load over normal.

In addition, whichever systems come online first often get a ton of traffic sent to them, which can immediately bring them back down if you don't have ways to prevent it. You will get a wave of systems coming back online, a ton of traffic hitting them, and then falling over again.

Now, I am sure Microsoft is used to this and has procedures and systems in place to mitigate the issues (I know we did).

However, sometimes if the right combination of services are failing, even the strategies you had to avoid this sort of failure can themselves fail.

For Copilot.

This seems to be the smoking gnu, now what would it be ...

(I've recently been revisiting the X-Files. Can recommend.)

I saw a frog smoking on The Little Rascals once, but never a gnu.

EDIT: Seems like now they confirmed that: "We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service."

@MSFT365Status

16m

We've not identified any recent change correlated with the start of impact; however, our investigation indicates the failed health checks may originate from a specific component that's responsible for processing server health. We've taken steps to prevent additional servers from being impacted while we work to return the affected servers to service. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as status.cloud.microsoft if the admin center is not available to you.

> Previous status: We're continuing to work through restarting and validating the affected servers to safely return them to service, and we're exploring opportunities to expedite this process. In parallel, we're assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery.

If failures started at some point in time then something must have changed just prior to that. If no changes in traffic were detected (no DDOS) then it must have been a change, be it code or config. Duuuh.

Not at all, they could have simply hit an unexpected behavior for their infra they hadn't seen, tested, or expected before. Global scale infra gets very, very complex, and tbh this is Microsoft... they're not very good at it.

More often than not, it's DNS :)

Edit: Oh, there it is.

Any other service that interacts with Outlook in some way will create downstream effects in other services expecting Outlook to work normally.

If your org is using Intune or Defender EDR then you probably also are impacted.

Or, rather, it's acting like it usually does.

I just assumed it was Teams being Teams.

Back on Window Mobile 6.1.

Battery life usage quickly improved. :)

Lamest tech company imo. Why dont you lay off some more staff, Satya, maybe that will fix the problem.

ThousandEyes Internet Insights offers a public outage map at https://www.thousandeyes.com/outages/ that is MASSIVELY more accurate (and faster to detect) than Down Detector because its based on actual telemetry and not on crowdsourcing.

They indicate sharepoint is getting blown out... again.

There will be a more detailed message when we finish the SII on our status page at the link I previously provided, but the short version is we took way more traffic than normal to our platform and the related workers were running out of memory.

No. It requires an account now, and they did away with the recent posts firehose.

I often know about outages dozens of minutes in advance of it being posted on official channels (or in the case of AWS, three days later...).

So what if the resolution is low because people can't log in to Fortnite and an Azure outage gets shown as an Epic Games outage. Doesn't matter. The live feed is incredibly reassuring from a "down for anyone else this instant, before official status page has a chance to see it?" Saves me so much time knowing whether it's a me-or-them issue.

And with Google is people complaining Chrome doesn't load their "pages". I bet they mean outlook.

That's a bold claim to make on HN.

Interesting: there's a huge correlation with everybody beginning to use LLMs.

And we dismiss it as being non-causal by saying it all started going downhill before the advent of LLMs?

I don't buy it. I think we're seeing the results of what happens when you hand the keys of the kingdom to LLMs.

It's been full speed downhill for many years, and the failure modes are pretty distinct.

Current industry best practice is to use LLMs improperly.

That doesn’t mean the code/result doesn’t still need to meet our engineering standards.

One of the best ways to deal with doing something the wrong way is to get rid of all the people who know how to do it correctly. That way no one knows any better, so no one has to confront the fact they're actually doing it wrong.

That is a software issue.

Service quality is in better hands after the layoffs, at least that’s what investors are led to believe.

The number of times it has spit out a python program where a much simpler bash script would do, is too many to count.

I have a pet theory that if you don't know what you really want, and aren't skilled enough to understand what you got, infra code is THE WORST.

Anecdote: I wanted a simple change to an ansible playbook today. GPT-6-Astra/codex came up with the most convoluted, brittle solution possible the first time, even though it was extending and already clear, idiomatic playbook. It took some amount of offensive and critical prompting to get it to use ansible's built in modules and tooling to do the same job - and do so with nearly 80% less configuration and like 1000% more human readability.

Some part of me harbours a sneaking suspicion that the "throw everything at it" ethos is by design, not as a defensive measure against crappy code, but as a way to ensure there's so much code and it's so convoluted orgs and operators (or developers) are stuck/addicted.

It's still a force multiplier - but it's by no means driverless, especially for existing/already-running infra.

https://status.cloud.microsoft/m365

Azure status does not document anything:

https://azure.status.microsoft/en-us/status

All that said... Stuff on my home PC started getting various DNS issues around the time my email started acting weird. Hard to say how widespread it is. It may be bigger than Microsoft even.

> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.

SignDrop is an unpatched Windows zero-day local privilege escalation (LPE) exploit that allows a standard user to gain NT AUTHORITY\SYSTEM privileges by abusing the Common Log File System (CLFS) kernel driver (clfs.sys). Security researcher Abdelhamid Naceri (also known as MSNightmare or Nightmare Eclipse) published a detailed technical write-up and functional proof-of-concept (PoC) code on GitHub on November 10, 2026.

Personally I kinda enjoy these outages…

Status page is down. Much of our org is halted.

Fingers crossed that Azure isn't impacted (seems fine so far)

(https://www.geekwire.com/2026/microsoft-makes-new-voluntary-...)

Just clarifying this in general, when a company makes a voluntary offer to some segment of employees, especially at this size, it is a statistics game of how many people accept the buy out.

They did not make the offer to 25% of the employees to downsize by 25%, they did it to downsize by 5% (or something like that), and then made the offer based on how many they expect to accept. This is specifically covered in this line of the geekwire article:

> Microsoft didn’t provide a projection for how many employees will accept, but the company told GeekWire it anticipates a much smaller share than the roughly 30% who took its earlier voluntary retirement offer, which went to longtime employees more likely to take the deal.

They probably expect 10-20% of those offered to take it, which would result in a 2.5-5% total downsizing.

Or is this just a gesture of goodwill to avoid people jumping the ship on their own?

And the other part is the "goodwill" you mention - if you jettison people for nothin en masse, word gets out, and make it hard to hire in the future

People who aren't motivated and/or don't back themselves to get another job will stay (i.e. probably the people you want to get rid of)

Claims do affect the rate they pay next year, but the company isn’t “on the hook” for you personally, at least not any more than they are for your social security income.

And everybody has spent a year letting AI write code. Correlation is not causation, but I wonder...

The page is showing a "Service Degredation" for "Microsoft 365 (Business or Enterprise)"

Updates below in reverse chronological order:

From the Thurdsay, November 12, 2026 at 7:30:36 PM UTC update:

Current status: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure. We're investigating what's causing these servers to become unavailable while we work to safely return them to service.

---

From the Thurdsay, November 12, 2026 at 7:16:03 PM UTC update:

Current status: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've also moved traffic for some services off the affected infrastructure to further reduce load, with additional traffic moves in progress.

---

From the Thurdsay, November 12, 2026 at 6:59:24 PM UTC update:

Current status: We've completed redistributing connection traffic across our worldwide infrastructure, and we're moving additional traffic off the affected infrastructure to further reduce load. We're also restarting affected servers to return them to service. In parallel, we're investigating whether the elevated traffic reflects a genuine increase in requests or a shift in how traffic is being routed across our infrastructure.

---

From the Thursday, November 12, 2026 at 6:32:25 PM UTC update:

Title: Users may be unable to connect to multiple Microsoft 365 services

User impact: Users may be unable to connect to multiple Microsoft 365 services.

More info: Potentially impacted services include:

- Exchange Online

- Microsoft Teams

- SharePoint Online

- Microsoft Copilot 365

- Microsoft Defender XDR

Current status: We’re investigating an issue impacting multiple Microsoft 365 services and we've determined the affected infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're restarting and repairing impacted portions of this infrastructure to restore capacity, and reviewing an unexpected increase in a specific type of service traffic to determine whether it's contributing to the elevated load. In parallel, we're evaluating options to redirect traffic to alternate infrastructure to expedite relief.

Scope of impact: This issue may affect users attempting to access the affected Microsoft 365 services.

---

From the Thursday, November 12, 2026 at 6:10:02 PM UTC update:

Scope of impact: This issue may affect users attempting to access the affected Microsoft 365 services.

User impact: Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods.

More info: Potentially impacted connection methods may include:

- Outlook on the web

- Messaging API (MAPI)

- Exchange ActiveSync (EAS)

- Representational State Transfer (REST) API

Current status: We’ve identified connectivity errors occurring on a portion of Exchange Online infrastructure which receives and processes users’ access requests. We’ve collected networking logs to review to further investigate the source of these errors and confirm our next steps.

Scope of impact: This issue may affect users attempting to access their mailbox in Exchange Online using the affected connection methods.

Next update by: Thursday, November 12, 2026, at 8:00 PM UTC

---

Aside: What with the nature of the Teams, OneDrive, etc, products being Sharepoint and Exchange in a trenchcoat this is probably creating quite a mess for services besides Exchange Online, too.

Edit: Looks like the status page needs a status page.

Edit: Verified w/ multiple other parties that Teams and OneDrive are having issues, too. Interestingly, Microsoft 365 Family services are working fine. That makes me wonder if that product is running on separate infrastructure (or just hasn't caught fire yet).

Edit: The RSS feed seems to load fairly quickly: https://status.cloud.microsoft/api/feed/mac

What MS has posted so far:

>> Microsoft 365 Status >> @MSFT365Status >> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543. 12:54 PM · Nov 12, 2026

>> Microsoft 365 Status >> @MSFT365Status >> While we're working to mitigate impact, we've confirmed the issue may affect Microsoft 365 service connectivity for users in any region, more information will be provided in the Microsoft 365 admin center under EX1550543.

>> Microsoft 365 Status >> @MSFT365Status >> We've determined a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're providing more information under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft

>> Microsoft 365 Status >> @MSFT365Status >> 20m >> We've begun redistributing connection traffic across our broader worldwide infrastructure to help balance the load. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft if the admin center is not available to you.

[0] https://x.com/MSFT365Status/status/2120938282204688468

The biggest site I work for, who went M365 hybrid last year, has incurred more Exchange downtime today than they had all of last year with their on-prem Exchange servers.

Sure, the program on your desktop computer is fine, but the Outlook app on your phone routes everything through MSFT's servers, so you may be impacted. Outlook.com is running EWS, so it would be down as well.

And finally, if you're talking to a layperson, they're not going to know what Exchange is. They just know they opened Outlook and it isn't working.

"School staff are currently unable to receive or send emails due to a nationwide Microsoft Outlook outage. We hope that the issue will be resolved soon and will send an update when we have more information."

It's funny how text-only niche forum that looks like it's running on RPi stuffed in someone's closet is routinely used to discuss active outages in multimillion/billion corps.

I think it's safe to say, if the server is unresponsive, the change is not effective.

Hope this entertains you while we can't get to our emails.

In other words, a day that ends in "y".

My company was recently acquired by a company that uses Office, so I'm using Microsoft products for the first time in 15 years. It's absolutely APPALLING how bad they are. I assumed they got fairly usable in the last 15 years, but it seems they've gone backwards.

For all my gripes about GSuite, ... I don't know how businesses can justify using software this bad.

O365 is Microsoft Office shoehorned into running in a web browser.

I have a teams app with Outlook integration and received a bunch of 502s to smba.trafficmanager.net and a my logs are riddled with "RestError Temporary connection issue when contacting service. Please wait before retrying request"

I will say this, having apps deployed on Slack and Teams, Slack rarely has issues (an exponential backoff is enough to simply never worry about my Slack integration). With Teams I have mysterious failures to debug at least 2x a year - and they're often not very transparent about them (often my first instinct is to search Twitter and find people complaining about the same thing).

While I don't expect this to be the case, I'm emotionally prepared for this to be some sort of "dicks out for Harambe"-style action protesting JH's departure from Nvidia, on a larger and more technical scale.

Edit: Typo.

My employer is very very close to MSFT. Both my employer and MSFT have been aggressively moving jobs to India, and firing people in the US. It's hard not to feel some schadenfreude.

A fictional story about AI could be that it rolled out its new document, spreadsheet, slides, etc. apps, knows the IPO is coming up and decided to make a lot of opportunities for people to sign up for their new release by DDosing their competitor.

None of the admin ran shops are down 1 day per year.

Because, well, once upon a time there was Exchange Server and MAPI (the "Messaging API"), and that actually worked pretty well, and pretty much everyone started using it (or one of its EWS/ActiveSync offshoots), but then the Internet happened and ruined everything, but we got MAPI-over-HTTPS eventually, which by that time had grown so many warts that nobody at Microsoft really understood it anymore, so that got deprecated, even though, well, everyone and everything still uses it.

The new hotness was Azure-slash-Office-365, and that's where the "new Outlook" web interface lived and (sort-of) continues to live, and the on-prem customers got stuck with the "Exchange Subscription Edition", which was basically Exchange 2019 plus security hotfixes at extortionate rates, but with none of the new functionality.

And, since MAPI continued to be really, really hard even in the age of Copilot, access from the new hotness to the deprecated on-prem servers was implemented via IMAP (LOL), but force-proxied via the outlook.com cloud/clownshow.

Which is why, right now, many Microsoft customers that thought they were self-hosting their email are entirely down. Lessons might be learned here, but I sort-of doubt it...

Sure, "New Outlook" on Windows is still entirely broken (including stuff like, oh, re-ordering mailboxes), but on Mac it's actually quite usable, and even allows you to switch off the IMAP proxying.

Also laughing at our ops guys who are now absolutely helpless and have people phoning them. I warned about this on our risk call and it was seen as low probability low risk. I hope it's down for a few hours :)

So in 10h

Now? I dont care Im logged off.

- live.com is down

- onedrive loads the UI, but all of my contents are missing

- MS Edge sync is down (503s )

Yup, major-major outage.

[1] https://github.com/customer-terms/github-online-services-sla

7:52 PM UTC: We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service.

7:30 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure. We're investigating what's causing these servers to become unavailable while we work to safely return them to service.

7:16 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've also moved traffic for some services off the affected infrastructure to further reduce load, with additional traffic moves in progress.

6:59 PM UTC: We've completed redistributing connection traffic across our worldwide infrastructure, and we're moving additional traffic off the affected infrastructure to further reduce load. We're also restarting affected servers to return them to service. In parallel, we're investigating whether the elevated traffic reflects a genuine increase in requests or a shift in how traffic is being routed across our infrastructure.

> I dislike Microsoft as much as the next guy, but many businesses impacted by these outages are completely innocent and don't deserve these consequences.

At no point is "keeping people alive" mentioned. Businesses use email for everything. Businesses usually don't care about where their email server is hosted. They just want to send emails. They shouldn't have to care either. I don't put blame on a business that happened to choose Outlook, one of the largest email providers, to host their email.

451 4.3.2 Temporary server error. Please try again later ATTR2 [MI3PEPF00008486.eurprd02.prod.outlook.com 2026-11-12Txxxxxxxxxxxxxx]

Sure GTA6 may be a slight uptick in the amount of data being downloaded like any new game being released, but I would wager that the amount of data they are normally pushing out for downloads just on a regular basis (wether new purchases, redownloading games, game pass, etc) is already quite high.

If they roll it out evenly the week prior, then today (1/7th) is just 75 PB. To get that done in a single day would require a sustained 6.9 Tbps.

I'm sure this is all handled by a CDN at some level... but again it's not nothing.

6.9 Tbps to get it done in a single day is even 3x less than the minimum on Steam in the last 48 hours https://store.steampowered.com/stats/content/ and they don't even have GTA VI to distribute.

Maybe if people are spinning up simple VMs and VPCs they can manage multicloud through a hub, but if you're using the big three for what they're meant for, you're using cloud DBs, API gateways, lambdas, and whatnot. With how much tuning, billing monitoring and specific configuration is needed, it seems like that'd be a hard thing to abstract. Even using an abstraction like Terraform to try to keep out of the weeds takes a lot of work, from what I remember five years ago.