> 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.
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).
That was never the promise. The nearest to that is the promise of multi-cloud or hybrid infrastructure, but neither of those have anything to do with outages of specific Microsoft services.
The "you can't possibly have better redundancy in your on-prem" was absolutely a sales pitch I heard to move to Microsoft 365.
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.
The service has redundancy, better than individual operators could provide on-prem. From the customer standpoint though, the service as a whole is a single point of failure: it either works or it doesn't.
It sounds like you are talking more about product reliability of M365 than you are about enterprise infrastructure reliability. M365 is a Microsoft product. M365 has no bearing on the credibility of cloud infrastructure as a whole, which is what your original comment spoke to.
YEah, that is not loading, along with the root status.cloud.microsoft , which MS links in their Xitter update [0]
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.
Everyone that is a whole stack programmer (say, kernel to webapp) has seen just how unnecessarily complicated everything has become. Watching it burn to the ground would be a pornographic miracle.
Funny thing is that my work's VPN that uses the MS authenticator just quit, immediately after I made that comment. So you are even more correct than usual.
I asked someone in our teams meeting if they were having issues with their outlook today. What followed was a 5 minute hate fest on outlook. I'm not a big fan, but was kind of surprised so many people genuinely hate it.
down detector always looks like this during big cloud service outages. i think partly because people don't actually know what services they're using and report wrong things, and partly because downdetector parses social media posts like "outlook is down but gmail still works" as outlook and gmail both being down.
Downdetector is a survey, not a detector, and suffers from user confusion when a high-profile service is actually down, as users start reporting unrelated things
The snarky but honest response is HackerNews/Reddit. But if you're trying for something that actually checks the sites you point it at instead of relying on users reporting "issues", a buddy of mine runs https://onlineornot.com/ and it seems generally more reliable.
Full Disclosure, this is a Cisco product and I work there.
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.
Yes, just to confirm, it seems that our platform is getting hammered at the moment and it's causing the page to take a long time to load or intermittently load. We are looking into it.
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.
The public outage map is primarily a marketing page, because customers receive deeper insights in-product. Given that most people discuss outages live/up-to-the-minute on Twitter, that is why its where we default to sharing.
It seems like one of the best methodologies there is? Real people reporting real outages of a service they use?
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.
How is it garbage? It's crowdsourced monitoring so sure, there will be false positives (especially when aws/cloudflare/azure/bgp services have a bad day), but it's one of the best indicators to quickly know if _something_ is going on.
not really, soon as i had a problem with outlook i went there and already saw user reports and a massive spike confirming it wasn't anything on my end.
As someone who ends up being unofficial downdetector-primary at a company, dealing with this shit and the fact that people cannot comprehend its mis-attribtion wastes so much of my time.
At the other extreme is Microsoft's own dashboard (https://azure.status.microsoft/en-us/status) whose methodology is so "rigorous" that it probably won't show anything about today's outage until next week, if at all!
My housemate texted me saying our internet is so slow because outlook wasn't loading. So I think lots of people associate email not working with entire internet not working..
With how many people are unable to associate a "broken" monitor with an unplugged HDMI/DisplayPort or power cable, it doesn't surprise me that most people would not make a disctinction between the "internet" and "Outlook".
This happens every time there's an outage. People see their email not working and go there and mark everything as down regardless of whether it is affected or not. There's nothing wrong with Gmail or AWS or Cloudflare or Facebook.
> Isn't this the company that is trying to get rid of 25% of their employees?
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.
The speed of change has accelerated drastically at some organizations, so even if quality stayed the same, the number of outages would increase because of the # of changes has condensed to happen over much shorter time frames.
A layoff of any real size has negative impacts to their unemployment insurance premiums and restricts their ability to file PERM for employees. Meeting those targets with voluntary separation prevents those impacts.
That’s not entirely accurate. Washington State pays unemployment, not the company. The state funds unemployment by taxing payrolls, but it’s much more indirect than most people think.
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.
I think both parties probably benefit; people who are more likely to take the offer are those who have another reason to leave (unfulfilled, etc). This will benefit the company in the long run because they can eventually replace them with someone who want to join (people applying for the job).
Can go the other way though: people who've been there for a while, are motivated and back themselves to get another job will take redundancy (i.e. the people you want to keep).
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)
You can at will fire but that doesnt stop lawsuits. Most of these require signing docs to get the payout. It is a way to cut cleanly and derisk the cut
The fact that it is always Big Even Number shows how stupid it is. Imagine if it was serious like "23.5176%" then you'd know they actually did their homework on leaning up operations instead of just cutting off limbs and seeing if it can still walk or not.
> 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.
Probably self inflicted by some code change, as they mention "specific type of service traffic".
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."
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.
> then something must have changed just prior to that
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.
Unexpected behavior doesn't happen out of the blue, it's not LLM, these are deterministic systems. It's usually config change or code change, not necessarily in the component that's misbehaving, but it is somewhere.
As someone who worked in infrastructure for a large global CDN, this sort of overload issues happen all the time when trying to bring infrastructure back online after an issue.
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.
This usually isn't a software quality issue, it's overcomplicated infrastructure failures cascading through a complex environment causing additional systems to fall over.
AI is good at incident diagnosis, but AI slop code may have actually caused this: designing to avoid cascading failures is something AI doesn't do so well
The place where I consistently see AI/LLMS/Agents/language-widgets-with-tools fail at making decent code (and more often configuration) is infrastructure.
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.
I work as a (depressed lol) sysadmin apprentice in a small MSP company (I live in Europe) and boy do I got a story about Ansible playbooks: We made an offer to one of our clients to automate the deployment of software to their computers (this is a client with around 150-200 employees, depending on whether you count only the "core" employees or also security and maintenance staff). Before we made and implemented this offer using Ansible, they did not have any sort of Software Deployment tool whatsoever, everything got installed fully manually.
(they also used to have local admin rights on all of their client computers until one employee got phished and literally gave away their personal ID card via a webcam)
In any case, guess who got to implement all the relevant playbooks for installing software and what tool they used for it? Our company literally handed the job to an intern who had no IT background whatsoever. I say this not to be mean, he was legitimately just at our company because a government program required him to do an internship.
He used Deepseek (our company does not believe in purchasing LLM subscriptions, at least not for us normal employees) to write literally all of the playbooks for any kind of software that mattered to our clients.
Now, as I said before, I am only an apprentice, and I am certainly not a good programmer by any means, but I read through parts of the Ansible documentation and had worked with it before, and I understood enough to at least be able to roughly judge whether a playbook made sense or was just way too complicated and convoluted.
I had to help this intern out multiple times, because he hadn't yet understood that, in order to write a functioning playbook, you first had to somewhat understand how to deploy a piece of software on a single test machine using CMD or Powershell syntax with an according .exe or .msi.
He simply prompted, pasted the playbook and then reprompted with the error codes from the failed playbook until it somehow worked or until I had to help him out.
This took place in December or November of last year and the playbooks are mostly still pretty shitty if I am being honest.
I did take away an important lesson from this "episode", though: LLMs can be very usefuly for writing code, or in this case, Ansible playbooks, but only if you have a somewhat decent and basic grasp of how software installation works via CMD/powershell and if you took the time to read through and learn about at least the basic Ansible concepts.
Since I am only an apprentice (on paper and in terms of my knowledge and how I get paid, not in terms of how much I am expected to earn for the company), I have painfully experienced how important it is to possess a certain level of understanding about the infra-related code and scripts that you would like LLMs to write for you, because otherwise it very quickly spirals out of control and starts throwing everything at the problem, just as you described.
With engineering rigor. They are fantastic tools for quickly navigating large codebases, ingesting large amounts of data, refactoring legacy code, compiling multiple formats of data, following defined patterns, and many other proper uses for the tools.
That doesn’t mean the code/result doesn’t still need to meet our engineering standards.
> Hopefully the people who feel that way are already close to retirement, so the choice won't have to be made for them.
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.
I really don't see the correlation, actually. On the contrary, I'm finding nasty defects with it that have been dormant for long and handwaved away, with repros to reveal them.
It's been full speed downhill for many years, and the failure modes are pretty distinct.
Sure, outlook.com is down, which is bad for everyone that chose to host their email there, I guess, but as an interesting side-effect, everyone with an on-premise Exchange server and "new Outlook" clients is affected as well.
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...
Exchange has been a circus for years. I think that's why everyone went O365 in the first place. Managing to have a paid up configuration where you go down when a cloud provider goes down but you're hosting it locally is absolutely stupid and I am laughing my ass off here.
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 :)
I don't think many orgs are using "new Outlook" to connect to on-prem Exchange because you miss a lot if you're only doing it via IMAP and "new" still doesn't support on-prem Exchange any other way. So all my clients are using classic Outlook with their on-prem Exchange servers (and really if they have EXO too because new Outlook isn't very good).
It's been gone-as-a-default for a few months now, but for a long time, "Classic Outlook" aggressively offered a one-toggle upgrade path to "New Outlook", and it got used.
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.
Is this related to GTA6 being pushed to consoles a week prior to launch?
Would they ever admit it if that were the case?
I want to believe this is the cause. It'd be especially funny because businesses were already anticipating the productivity loss when GTA6 comes out, but now we have actual productivity loss because of this outage (and it's affecting people who were never going to play the game anyway, lol)
I want to believe that cause is that all the world's computing power is dedicated to calculating the incredibly large balance in my checking account but my desire is the only thing I can find to support that hypothesis.
It is basically nothing once you remember the cloud isn't one computer either. I want to say Azure was already millions of (beefy ass) severs over hundreds of datacenter locations organized into dozens of zones, and not all of those servers in each region are assigned to the same sets of services.
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.
Why would this be the case? Games preloading has been a thing for many years. This isnt like an MMO launch that there is additional impact when the game is being played.
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.
Nah, no way they're getting rid of their M.C.-Escher-esque 'Forefront' mail-disappearance-machine-that-nobody-in-Microsoft-seems-to-understand-or-control, but, yeah, even their Internet-facing infrastructure seems unhappy:
451 4.3.2 Temporary server error. Please try again later ATTR2 [MI3PEPF00008486.eurprd02.prod.outlook.com 2026-11-12Txxxxxxxxxxxxxx]
Strangely, Teams chat is working fine here. Anything in Teams that is tied to other parts of O365, including the calendar, is dead. I'm currently watching a training video on sharepoint.com, so that's fine too, for now.
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.
That kind of depends on what you mean by "Outlook".
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.
Amateur hour at Microsoft.
It baffles me how many companies can’t figure out how to make a status page that can handle the high loads it’ll have to sustain when the service they monitor is down. That’s pretty much the only reason to have a status page in the first place.
GH and MS have been having a tough past couple weeks. Actions (hosted on shitty azure cloud) have been piss poor lately. I am honestly surprised GH and MSFT have the gall to continue advertising 99.9% uptime [1]
Three 9's is .36525 days per year. So if this one is resolved within 8 hours, that's about .999 uptime. (assuming they only have one such outage this year.)
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.
That's a very painful lesson in "the cloud is just someone else's computer" to a crowd that normally are exposed to ideas like "software and IT are not our core competency"
The idea is that it's someone else's computers that are managed more comprehensively than you could reasonably do yourself. But if you choose Microsoft to provide such a service for you, I don't know what to tell you.
To be honest, Microsoft has much better chance of actually achieving that (almost) 100% uptime than your company's own IT department self-hosting things.
I like to dogpile on M$ as much as the next guy, but this feels like a heavy strawman.
> 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.
It's a shame there isn't a well-standardized, free and open protocol for delivering email that could be run on inexpensive modestly provisioned hardware.
I mean, they made us take down our departmental run email (presumably postfix) and forced us to make them aliases to university-wide exchange (with crappy support for open source mail clients no less). So I don't think my org is Innocent here...
Did Anthropic's new release this week include an AI rollout plan (i.e. not approved by humans) to take down Office and Outlook for a lot of enterprises? I half-snarkily ask since we have seen "rogue AI" headlines before.
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.
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.
Well, my mac CI runs aren't being picked up, and they eventually fail because of it. So maybe wherever connects the orchestrator to the machines is having issues.
Neither email nor Teams is working at my non-tech megacorp employer. I wonder how much of the economy this is impacting.
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.
Office 365 parts goes down all the time. Usually around 20:00 CEST time, not sure if that is prime change time over in the USA but very handy as it is usually fixed next day.
GitHub the other day went down because of an influx of anonymous users. Microsoft has hinted that surging connections caused the outage. I wonder if these two are linked?
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.
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.
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.
In maintenance, sometimes the dumb solution is the best. The servers that ran amazon.com had a memory leak and were subsequently restarted. This hack continues for years because it was the most cost-effective thing to do.
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
I worked on multi-million dollar airplanes. If a pilot called me with an issue and hadn't rebooted the plane (on the ground), I wouldn't even talk to them. Rebooting isn't always a bad solution to technology.
It's not a bad solution, it definitely should be tried. But I'm still rather shocked to see it in official notes, especially this "late" in the timeline.
Powercycling is a designed method to bailout Cisco routers. If you botch a configuration command and lose connection, you can have someone powercycle it to restore you last good configuration. Its not just a joke it really works more often than I'd like to admit.
copilot, make this doom and gloom situation sound better. assume you're using the voice of a friendly but intensely focused sysadmin. use only neutral language.
So the servers are ok but many of the health checks are failing and so the servers are taken off rotation, increasing load on other servers. I'm sure it's more complicated than it seems but from my POV this looks like amateur hour at Microsoft.
I'm not thrilled with what they've done to Windows lately myself, but this is just rude.
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 they have SLAs of no significant downtime. It does not guarantee that the SLAs can never be missed, just that there will be consequences when it is missed. Lawyers and accountants and sales folks will sort out the compensation payments that come back to the customers and try to negotiate relationships back to a healthy state.
Individual talent is irrelevant when you have a company culture that rewards the opposite of that. Any talented person working at Microsoft knows that they are dealing with structural problem that force MS products to be massive piles of shit. There isn't much an talented individual can do about that.
To be fair: I want the people who can speak most competently to a problem to be working on it versus writing commentary. Those highly-technical people can shine in the postmortem report.
I disagree; the communication aspects - including external - are a hugely important part of any incident response. IME the biggest challenges in these situations are the many levels & combinations of communication and coordination. You don't need your best DevOps person doing it, but there should be plenty of competent technical product managers or engineering managers who could do this well.
And that is a good thing. Well, maybe not good. But the last thing you need in a crisis is to pull people away from fixing the problem and make them type up status updates. Admittedly, having tech knowledge would help the writers - a technical incident management team would be better. But ain't nothing wrong with letting the PR folks write up words while the tech folk work on problem solving.
Amateur hour? Not sure if you've lived through one of these cascading failures, but they are hard to design against, hard to load/chaos test for, and hard to recover from. The key is that this is a dynamic load, not a static load; and it's normally amplified by uncontrolled retry behavior by clients.
In retrospect, the cause and cure are obvious to everyone.
Many of us insist upon not building Rube Goldberg machines that cannot be reasoned about precisely for this reason.
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.
Except for the fact that it seems like most Microsoft outages are self owns. I'm not sure how many times we've had outages due to bad deployments that somehow made it to their global infrastructure and only got noticed when customers notified.
Plenty of internal accounts from previous employees highlight this.
This sounds suspiciously what occurred when I was working at a large motor sports company. We had a major release of new year models coming out on the website. The deployment went super smooth and then in about 30 mins the site was crashing. Since we were a huge MS client, almost everything we ran was all MS top to bottom.
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.
Newest update says that wasn't the issue after all. They say relatively small loads are actually causing servers to become unresponsive and have to be restarted.
They still don't know why this "core process" is maxing out the processor for no reason.
I can't stand it when I see armchair analysts making claims like this.
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?
I feel bad for the people working on this. It sounds like desperation is increasing.
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.
they are furiously typing at their agents hoping they can figure out what to do. Getting glimps of hope everytime claude says "I found it." only for their hopes to be crused at "Turns out ...". The clown show at Microsoft is surreal.
The 11:05:31 PM UTC update is is the first since the outage began that feels hopeful.
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.
> For reasons that I cannot fathom, Microsoft wants to act as the relay to my self-hosted e-mail account
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 would strongly doubt (though not completely rule out) that Microsoft is reading your personal mail hosted on your personal mail server. Like what would that even look like, their IMAP client is forwarding email to headquarters?
BUT, more likely, it's some sort of "check in" or "dial home" feature that isn't working. Or plausibly, maybe they count "local user checked email" and their analytics endpoint is down.
Regardless, it's definitely surprising that a traditional desktop application would be blocking when only polling from local/trusted data sources.
"New" Outlook does route all traffic through Microsoft servers. I assume it's so you can get a "unified" mail look on all your devices (phone, etc), but likely a nice source of data mining
Personally, I can't reconcile having a self-hosted email server and using Outlook to access said email.
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.
It took 30 seconds to open a "local" file in Word, and my Outlook email wasn't updating.
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.
I'm in a similar situation, using Microsoft again after 13+ years. Outlook and teams I expected to be garbage, but Word and Excel was really surprising. I get it that everyone has that one feature of excel that is not available in gSuite so they need it. But UX in general is so much superior at Google it's baffling how they let it's workhorse fall behind so much.
anyone else just watch the admin portal post an update and then roll it back to the previous update....guess it didn't work. "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." was the old message from 7:52 UTC now it rolled back to 7:30 UTC update again
I suspect some possible relation to SignDrop or attempts to patch it.
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.
Not impossible, but very unlikely. CLFS isn’t remotely reachable, it's a kernel driver reached through local API calls and has no network listener. AFAIK the historical CLFS CVEs are all rated as local.
Yeah every IT dept is sending out that notification. Someone replied with 'When do you expect it to be back online?" to which I LOL emoted at the moment. I think I'm a jerk. But how can you ask such a question- as if they planned a time to restore services and aren't working to restore it as quickly as possible?
For whatever reason 6.1 Sol is completely lobotomized for me this morning, so it wasn't helping much with the investigation, but it was pretty clear that MSFT was having issues.
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).
My company is being pressured very aggressively by Microsoft to migrate all our users from us-managed Exchange to Microsoft-managed Exchange Online. Guess which users still have email today and which do not…
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.
> 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.
I think it's safe to say, if the server is unresponsive, the change is not effective.
"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."
Update from Microsoft:
"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."
Update as of 10 minutes ago implies that didn't work:
> 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.
So health checks were correct… this solution of silencing the first symptom is probably just adding to the problem. I am afraid they may be opening the door for the fire trucks and getting some other kind of intrusion instead. Better they shut it down for day and do proper fix.
The 11:05:31 PM UTC update is is the first since the outage began that feels hopeful.
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.
The code by itself doesn't tell you how the various components of a complex distributed system interact in a failure condition with clients hammering retries.
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
Outlook calendar won't load? Is this part of the outage? Unfortunately, I downloaded several updates and rebooted. I'm not sure if this is because of the updates or the Microsoft outage.
russian hackers in Kazan hopping thru
Sluck Belarus South Africa Brazil hitting MS backdoor w/ zero day Cve-2026-124194 RuskiNet group hit East U in Boydtin Virginia. Pro Iranian.
It's insane that Microsoft continues to have global outages. Tech debt is real, service delivery on a planetary level means change is measured and deliberate, but...it's been years. YEARS.
My last email was received at 5.5 hours ago. Teams chat and meetings are the only thing in Microsoft 365 that seem to be working. All our Azure infrastructure seems fine so this is something 365-specific.
Everyone has occasional outages but this is the worst 365 outage our org has seen since starting with M365 in 2019.
I note that Microsoft became heavily off-shored, on-shored and AI-pilled/vibe-coded in recent years. With lots of layoffs of the highest caliber and/or most experienced engineers.
testplzignore | 5 hours ago
> 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.
EvanAnderson | 5 hours ago
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
vachina | 5 hours ago
nazgulsenpai | 5 hours ago
moronicles | 5 hours ago
EvanAnderson | 5 hours ago
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.
SoftTalker | 4 hours ago
moronicles | 4 hours ago
nazgulsenpai | 4 hours ago
toss1 | 4 hours ago
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
neilsimp1 | 5 hours ago
Aboutplants | 5 hours ago
Waterluvian | 5 hours ago
lajy | 5 hours ago
Aboutplants | 5 hours ago
inChargeOfIT | 4 hours ago
duxup | 5 hours ago
Personally I kinda enjoy these outages…
infamouscow | 2 hours ago
bix6 | 5 hours ago
throwaway_1016 | 5 hours ago
geekamongus | 5 hours ago
jp191919 | 5 hours ago
LtdJorge | 5 hours ago
sonicrocketman | 5 hours ago
marcosdumay | 5 hours ago
Or, rather, it's acting like it usually does.
tsherb | 5 hours ago
function_seven | 5 hours ago
I just assumed it was Teams being Teams.
ratelimitsteve | 4 hours ago
hinkley | 4 hours ago
com2kid | 4 hours ago
Back on Window Mobile 6.1.
Battery life usage quickly improved. :)
marcosdumay | 4 hours ago
burningChrome | 3 hours ago
abirch | 3 hours ago
Khaine | an hour ago
notatoad | 4 hours ago
fmbb | 4 hours ago
coldbrewed | 4 hours ago
midas89 | 4 hours ago
If your org is using Intune or Defender EDR then you probably also are impacted.
jwnin | an hour ago
peanut-walrus | 4 hours ago
cwillu | 3 hours ago
hunter2_ | 3 hours ago
kube-system | an hour ago
Any other service that interacts with Outlook in some way will create downstream effects in other services expecting Outlook to work normally.
sonicrocketman | 5 hours ago
SomeonesAccount | 5 hours ago
Icathian | 5 hours ago
sonicrocketman | 5 hours ago
marifjeren | 5 hours ago
Icathian | 5 hours ago
ceejayoz | 4 hours ago
pacoWebConsult | 4 hours ago
ceejayoz | 4 hours ago
No. It requires an account now, and they did away with the recent posts firehose.
krazydad | 4 hours ago
andrewinardeer | 5 hours ago
dymk | 4 hours ago
tristor | 4 hours ago
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.
MadrasTh0rn | 4 hours ago
They indicate sharepoint is getting blown out... again.
justusthane | 4 hours ago
tristor | 3 hours ago
tristor | 3 hours ago
Stiereng | 2 hours ago
tristor | 2 hours ago
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.
ishtanbul | 3 hours ago
janlukacs | 3 hours ago
xtiansimon | 2 hours ago
stronglikedan | 2 hours ago
tristor | an hour ago
VCFundedGenYer | 2 hours ago
spelunker | 2 hours ago
akersten | 4 hours ago
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.
inChargeOfIT | 4 hours ago
cush | 4 hours ago
OGWhales | 3 hours ago
greenchair | 4 hours ago
pigggg | 3 hours ago
denysvitali | 3 hours ago
rdiddly | 2 hours ago
NetMageSCW | 54 minutes ago
dudus | 5 hours ago
And with Google is people complaining Chrome doesn't load their "pages". I bet they mean outlook.
busymom0 | 4 hours ago
MiguelPablo | 3 hours ago
paxy | 5 hours ago
patrickmay | 4 hours ago
That's a bold claim to make on HN.
[OP] dkpk | 5 hours ago
NichoPaolucci | 5 hours ago
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-...)
eightysixfour | 5 hours ago
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.
NichoPaolucci | 5 hours ago
AnimalMuppet | 4 hours ago
And everybody has spent a year letting AI write code. Correlation is not causation, but I wonder...
esseph | 3 hours ago
maxboone | 4 hours ago
Or is this just a gesture of goodwill to avoid people jumping the ship on their own?
tesin | 4 hours ago
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
coredog64 | 4 hours ago
gmane | 4 hours ago
evenhash | 3 hours ago
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.
StableAlkyne | 4 hours ago
NotMichaelBay | 4 hours ago
ifwinterco | 4 hours ago
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)
rustystump | 4 hours ago
asdff | 4 hours ago
hn_submit | 4 hours ago
nightski | 3 hours ago
dastari | 3 hours ago
bearjaws | 5 hours ago
agumonkey | 5 hours ago
debo_ | 5 hours ago
francisofascii | 5 hours ago
FranOntanaya | 4 hours ago
pona-a | 4 hours ago
dbvn | 5 hours ago
JPascal_ | 5 hours ago
OhMeadhbh | 4 hours ago
nazgulsenpai | 5 hours ago
DDOS?
iAMkenough | 5 hours ago
nazgulsenpai | 5 hours ago
millerm | 4 hours ago
FranOntanaya | 4 hours ago
Edit: Oh, there it is.
gloosx | 4 hours ago
bix6 | 4 hours ago
datadrivenangel | 4 hours ago
ingen0s | 4 hours ago
isomorphic | 4 hours ago
card_zero | 3 hours ago
cidd | 2 hours ago
rawbee1989 | 3 hours ago
ahartmetz | 57 minutes ago
For Copilot.
bitteralmond | 4 hours ago
nazgulsenpai | 3 hours ago
cozzyd | 37 minutes ago
bombcar | 4 hours ago
This seems to be the smoking gnu, now what would it be ...
reaperducer | 3 hours ago
I saw a frog smoking on The Little Rascals once, but never a gnu.
stn8188 | 3 hours ago
cuu508 | 2 hours ago
junga | an hour ago
BLKNSLVR | an hour ago
(I've recently been revisiting the X-Files. Can recommend.)
berkeleyjunk | 55 minutes ago
BLKNSLVR | 48 minutes ago
anvuong | 4 hours ago
canibalrex | 2 hours ago
lossolo | 4 hours ago
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."
esseph | 3 hours ago
@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.
kabdib | 2 hours ago
drillsteps5 | an hour ago
> 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.
esseph | 32 minutes ago
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.
drillsteps5 | 11 minutes ago
More often than not, it's DNS :)
MadrasTh0rn | 3 hours ago
browningstreet | an hour ago
cortesoft | 29 minutes ago
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.
matt3210 | 5 hours ago
worik | 5 hours ago
ocdtrekkie | 5 hours ago
iAMkenough | 5 hours ago
Service quality is in better hands after the layoffs, at least that’s what investors are led to believe.
bitteralmond | 4 hours ago
davidee | 4 hours ago
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.
MiguelPablo | 3 hours ago
(they also used to have local admin rights on all of their client computers until one employee got phished and literally gave away their personal ID card via a webcam)
In any case, guess who got to implement all the relevant playbooks for installing software and what tool they used for it? Our company literally handed the job to an intern who had no IT background whatsoever. I say this not to be mean, he was legitimately just at our company because a government program required him to do an internship.
He used Deepseek (our company does not believe in purchasing LLM subscriptions, at least not for us normal employees) to write literally all of the playbooks for any kind of software that mattered to our clients.
Now, as I said before, I am only an apprentice, and I am certainly not a good programmer by any means, but I read through parts of the Ansible documentation and had worked with it before, and I understood enough to at least be able to roughly judge whether a playbook made sense or was just way too complicated and convoluted.
I had to help this intern out multiple times, because he hadn't yet understood that, in order to write a functioning playbook, you first had to somewhat understand how to deploy a piece of software on a single test machine using CMD or Powershell syntax with an according .exe or .msi.
He simply prompted, pasted the playbook and then reprompted with the error codes from the failed playbook until it somehow worked or until I had to help him out.
This took place in December or November of last year and the playbooks are mostly still pretty shitty if I am being honest.
I did take away an important lesson from this "episode", though: LLMs can be very usefuly for writing code, or in this case, Ansible playbooks, but only if you have a somewhat decent and basic grasp of how software installation works via CMD/powershell and if you took the time to read through and learn about at least the basic Ansible concepts.
Since I am only an apprentice (on paper and in terms of my knowledge and how I get paid, not in terms of how much I am expected to earn for the company), I have painfully experienced how important it is to possess a certain level of understanding about the infra-related code and scripts that you would like LLMs to write for you, because otherwise it very quickly spirals out of control and starts throwing everything at the problem, just as you described.
SoftTalker | 4 hours ago
worik | 5 hours ago
That is a software issue.
cheesemonk66 | 4 hours ago
unethical_ban | 4 hours ago
elxr | 3 hours ago
combobyte | 4 hours ago
TacticalCoder | 3 hours ago
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.
CamperBob2 | 3 hours ago
10111001 | 3 hours ago
Current industry best practice is to use LLMs improperly.
hackerbrother | 2 hours ago
NichoPaolucci | 2 hours ago
That doesn’t mean the code/result doesn’t still need to meet our engineering standards.
CamperBob2 | 2 hours ago
10111001 | 24 minutes ago
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.
perching_aix | 2 hours ago
It's been full speed downhill for many years, and the failure modes are pretty distinct.
vconnor | 2 hours ago
skeaker | an hour ago
robotnikman | 5 hours ago
corvad | 5 hours ago
tanseydavid | 4 hours ago
OhMeadhbh | 4 hours ago
OnceMoreUntoThe | 5 hours ago
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...
goodthink | 5 hours ago
busymom0 | 4 hours ago
gilfaethwy | 4 hours ago
Ungh | 4 hours ago
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 :)
greatquux | 4 hours ago
OnceMoreUntoThe | 4 hours ago
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.
arboles | 4 hours ago
ericfrederich | 5 hours ago
I want to believe this is the cause. It'd be especially funny because businesses were already anticipating the productivity loss when GTA6 comes out, but now we have actual productivity loss because of this outage (and it's affecting people who were never going to play the game anyway, lol)
Juvination | 5 hours ago
ratelimitsteve | 4 hours ago
ericfrederich | 4 hours ago
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.
zamadatix | 4 hours ago
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.
nerdjon | 4 hours ago
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.
ChrisArchitect | 5 hours ago
cromka | 5 hours ago
OnceMoreUntoThe | 4 hours ago
451 4.3.2 Temporary server error. Please try again later ATTR2 [MI3PEPF00008486.eurprd02.prod.outlook.com 2026-11-12Txxxxxxxxxxxxxx]
suzzer99 | 4 hours ago
bawolff | 3 hours ago
vdkyes | 5 hours ago
fock | 4 hours ago
nhhvhy | 3 hours ago
sonicrocketman | 5 hours ago
JPascal_ | 5 hours ago
Foobar8568 | 5 hours ago
flkiwi | 4 hours ago
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.
xp84 | 4 hours ago
Hope this entertains you while we can't get to our emails.
flufluflufluffy | 3 hours ago
SirFatty | 4 hours ago
thesuitonym | 3 hours ago
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.
tony69 | 4 hours ago
rolph | 4 hours ago
nxobject | 4 hours ago
xyst | 4 hours ago
[1] https://github.com/customer-terms/github-online-services-sla
OhMeadhbh | 4 hours ago
likelybot | 4 hours ago
LoganDark | 4 hours ago
azalemeth | 4 hours ago
hdgvhicv | 3 hours ago
When your outsourced system to Microsoft goes down every few months your boss can’t yell at you
Outsourcing is about shifting blame elsewhere
bawolff | 3 hours ago
antonvs | 2 hours ago
NetMageSCW | 10 minutes ago
TaLiTr | 4 hours ago
LoganDark | 4 hours ago
joseda-hg | 4 hours ago
Detrytus | 3 hours ago
6031769 | 3 hours ago
jjice | 3 hours ago
> 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.
fock | 4 hours ago
SoftTalker | 3 hours ago
datakan | 3 hours ago
mrguyorama | 3 hours ago
destitude | 3 hours ago
NetMageSCW | 9 minutes ago
cozzyd | 40 minutes ago
Surac | 4 hours ago
loloquwowndueo | 4 hours ago
Kye | 4 hours ago
nullorempty | 3 hours ago
bastien-brd | 4 hours ago
friendlypenguin | 4 hours ago
mattbrewsbytes | 4 hours ago
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.
drillsteps5 | 4 hours ago
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.
steve1977 | 4 hours ago
emschwartz | 4 hours ago
rvz | 4 hours ago
One of GitHub's services will be down again by next week.
mook | 4 hours ago
emschwartz | 4 hours ago
piker | 2 hours ago
dist-epoch | 2 hours ago
shdjhdfh | 32 minutes ago
redwood | 4 hours ago
caycep | 4 hours ago
thraway2079081 | 4 hours ago
hdgvhicv | 3 hours ago
stanac | 3 hours ago
morkalork | 3 hours ago
croes | 3 hours ago
chromatin | 3 hours ago
croes | 3 hours ago
cwbriscoe | 6 minutes ago
MadrasTh0rn | 4 hours ago
thraway2079081 | 4 hours ago
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.
Caloric3002Swed | 4 hours ago
fyrabanks | 3 hours ago
Caloric3002Swed | 3 hours ago
So in 10h
Now? I dont care Im logged off.
anuptalwalkar | 4 hours ago
tonymet | 4 hours ago
- 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.
Lynicis | 4 hours ago
ahartmetz | 55 minutes ago
andrewinardeer | 4 hours ago
beowulfey | 4 hours ago
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.
beowulfey | 4 hours ago
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.
wmchen | 3 hours ago
beowulfey | 3 hours ago
ArcHound | 3 hours ago
justonceokay | 3 hours ago
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
jimmaswell | 3 hours ago
onefiftymike | 3 hours ago
ArcHound | 3 hours ago
mapontosevenths | 2 hours ago
taftster | 9 minutes ago
bawolff | 3 hours ago
red-iron-pine | an hour ago
we "bounce" the servers when on calls with customers.
icameron | 38 minutes ago
martinald | 3 hours ago
red-iron-pine | an hour ago
dudus | 3 hours ago
6031769 | 3 hours ago
bradleyjg | 3 hours ago
ahartmetz | an hour ago
mapontosevenths | 2 hours ago
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.
fyrabanks | an hour ago
lots of nines means not having significant downtime. we passed 99.99% hours ago, and we're on the way to 99.9%
codingdave | 9 minutes ago
ifwinterco | an hour ago
Almost certainly not the fault of individual people, it's a management failure of course
zmgsabst | 55 minutes ago
I agree there are many talented people at Microsoft, but I don’t see the professionalism in this incident.
eddythompson80 | 48 minutes ago
steve1977 | 3 hours ago
semiquaver | 3 hours ago
EvanAnderson | an hour ago
skeeter2020 | an hour ago
codingdave | an hour ago
Actual tech write-ups can come later.
shermantanktop | an hour ago
In retrospect, the cause and cure are obvious to everyone.
infamouscow | 49 minutes ago
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.
Den_VR | 29 minutes ago
What a great phrase!, can I use that in conversation?
llama052 | 39 minutes ago
Plenty of internal accounts from previous employees highlight this.
burningChrome | an hour ago
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.
mminer237 | 56 minutes ago
They still don't know why this "core process" is maxing out the processor for no reason.
NoPicklez | 19 minutes ago
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?
jenimac926 | 3 hours ago
no-dr-onboard | 3 hours ago
hammock | an hour ago
lazyasciiart | 43 minutes ago
elmo2you | 41 minutes ago
outworlder | 22 minutes ago
testrun | 14 minutes ago
EvanAnderson | 3 hours ago
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.
eddythompson80 | an hour ago
Rantenki | 44 minutes ago
fock | an hour ago
piker | 49 minutes ago
reaperducer | 46 minutes ago
Reddit-level speculation.
llama052 | 40 minutes ago
EvanAnderson | 43 minutes ago
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.
matt3210 | 22 minutes ago
ajdude | 9 minutes ago
Eji1700 | 55 minutes ago
I feel for those stuck in there. The outage going on for this long has got to be fucking brutal.
k_sze | 3 hours ago
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.
Telemakhos | 3 hours ago
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.
kspacewalk2 | 3 hours ago
taftster | 3 minutes ago
BUT, more likely, it's some sort of "check in" or "dial home" feature that isn't working. Or plausibly, maybe they count "local user checked email" and their analytics endpoint is down.
Regardless, it's definitely surprising that a traditional desktop application would be blocking when only polling from local/trusted data sources.
ActionHank | 3 hours ago
rstupek | 3 hours ago
brokenmachine | an hour ago
BLKNSLVR | an hour ago
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.
amanaplanacanal | an hour ago
BLKNSLVR | 53 minutes ago
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).
janfoeh | 30 minutes ago
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.
SSLy | 36 minutes ago
post-it | 29 minutes ago
prepend | 4 minutes ago
andyfilms1 | 14 minutes ago
zalebz | 7 minutes ago
lousken | 21 minutes ago
rconti | 3 hours ago
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.
dudus | 3 hours ago
SoftTalker | 3 hours ago
O365 is Microsoft Office shoehorned into running in a web browser.
jenimac926 | 3 hours ago
utsavo_afk | 3 hours ago
utsavo_afk | 3 hours ago
z500 | 3 hours ago
htrp | 3 hours ago
CerebralCerb | 3 hours ago
butz | 3 hours ago
JPascal_ | 3 hours ago
tech_ken | 3 hours ago
rossdavidh | 2 hours ago
sgt | 3 hours ago
monkaiju | 3 hours ago
nashashmi | 3 hours ago
infn8loop | 3 hours ago
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.
stackghost | 3 hours ago
antx | 2 hours ago
game_the0ry | 3 hours ago
Lamest tech company imo. Why dont you lay off some more staff, Satya, maybe that will fix the problem.
icameron | 36 minutes ago
at1as | 3 hours ago
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).
semiquaver | 3 hours ago
RajT88 | 3 hours ago
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.
fock | 2 hours ago
jwnin | an hour ago
dbvn | 2 hours ago
I think it's safe to say, if the server is unresponsive, the change is not effective.
isquaredr | 2 hours ago
ifwinterco | 50 minutes ago
Maximilian_Bet | 2 hours ago
zmmmmm | 2 hours ago
xtiansimon | 2 hours ago
whatever1 | 2 hours ago
None of the admin ran shops are down 1 day per year.
trentor | 2 hours ago
kittiesunicorns | 2 hours ago
"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."
soundworlds | 2 hours ago
"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...
Rantenki | an hour ago
> 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.
cgio | 55 minutes ago
EvanAnderson | an hour ago
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.
jp191919 | an hour ago
BLKNSLVR | an hour ago
But maybe don't understand it because they didn't write it themselves?
LadyCailin | an hour ago
BLKNSLVR | an hour ago
2. Art imitates Life
3. Goto 1
https://youtu.be/3TNpOD6bov8
ifwinterco | an hour ago
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
cidd | 2 hours ago
apercu | 2 hours ago
rwmj | 2 hours ago
rurp | 59 minutes ago
rainee | 2 hours ago
rainee | 2 hours ago
jobe777 | 2 hours ago
jobe777 | 2 hours ago
ArcHound | an hour ago
tiahura | an hour ago
bharathreddy497 | an hour ago
jwnin | an hour ago
bigwheels | an hour ago
analog31 | an hour ago
tatersolid | an hour ago
Everyone has occasional outages but this is the worst 365 outage our org has seen since starting with M365 in 2019.
burnedbyhell | 59 minutes ago
tcoff91 | 58 minutes ago
layoric | 57 minutes ago
syngrog66 | 55 minutes ago
microsucks | 37 minutes ago
cozzyd | 36 minutes ago
vermontdevil | 18 minutes ago