Ex-MSFT here, sharing my outdated POV based on working on a product that was using Microsoft Exchange and therefore was hooked onto the email delivery pipeline.
Note that the infra for M365, Azure etc is different. They would be running on servers hosted in MSFT DCs but have completely different CI/CD pipelines. M365 services have their own deployment pipelines and it takes on the order of weeks to deploy your changes to production.
Considering the fact that Outlook is down, clearly email doesn’t seem to be working. So email uses something called Microsoft Exchange Server, there used to be an on-premises version of this but MS stopped supporting it to run the cloud version hereby called M365. Email is one big “macro-service”, if you’re running Windows Server, look at the process called “EdgeTransport.exe” this is responsible for sending/receiving email on Windows Servers. There are probably multiple 100s of services supported by 100s of teams that are run while email is routed from sender to receiver via MSFT Exchange servers. My recollection is that even if one of these services goes down or introduces latency in the pipeline, it caused a major incident. When I was working in M365 Security in 2024, this Exchange Server pipeline was called “legacy” because it’s one big .NET Framework service. I don’t know if they upgraded to .NET core but developing on this was as HN comments say, very janky.
The reason Teams doesn’t seem to be down is that Teams services are completely different and are written using .NET Core and have their own separate release pipeline. It was much easier to interact with Teams services. I actually worked closely with the team that was responsible for ingesting Teams messages to the customer’s data store. Their code base was much more modern and easy to understand. Exchange Server not so much.
I don’t know if what I said is accurate but know that Exchange server code was like a fossil that didn’t change as much, over the ~5 years I worked on it from 2019-2024.
This hasn't been the case for a long time. Unfortunately there are micro services that can still bring down the system if there's a bad enough bug. That's not supposed to be able to happen as updates roll out over a period of time. Unfortunately you can still get bit if another update creates a bug that takes out instances faster than they can be recreated.
> So email uses something called Microsoft Exchange Server, there used to be an on-premises version of this but MS stopped supporting it ...
On-premises Exchange is still supported and licensed. It's a subscription instead of a perpetual license.
> I don’t know if what I said is accurate but know that Exchange server code was like a fossil that didn’t change as much, over the ~5 years I worked on it from 2019-2024.
Exchange is a mature product (albeit not without its flaws). Its era of change was between its 2007 and 2013 versions (inclusive) when it was made more modular and many parts were ported to the .NET runtime. The 2016, 2019, and now Subscription Edition codebases were more of an evolution and has much less churn.
"Microsoft Teams: Most of the core functionality including joining calls, meetings, group chats, and channel messages are not impacted.
Scenarios that depend on Exchange Online, including Calendar related failures with scheduling, invites, viewing, and meeting edits. Creation of Live or Virtual events fail. Failures with Copilot responses for outlook, calendar, or M365 files, read history, or adding to new chats. Navigating to App chats, adding new contacts or syncing contacts in settings fail. Standard channels are working fine but users may experience the inability to create or delete private or shared channels."
What is driving me nuts is that we still heavily rely on email. Even to the point were we are unable to get notifications other than that.
I work at a fortune 500 company and they got me, 3 hours after I started working , the basic info about the obvious the internet is already screaming at you.
Since we are responsible for a large web application I tried to reach out to people through VIVA (yes, we only make use of that) and we managed only to reach about 2-3% of the user base. Information-wise it's like a blackout. For living in 2026 this is completely unacceptable.
It’s interesting how relative this is, reading by the comments and stories around them. A previous coworker started computing in the punch card era and would tell stories of dropping your stack of cards and having to reorder them, using the printouts to debug, and so on. And helping develop what’s now known as fork() for processes (although it predated fork and he had his own name for it), and helping develop a commercial RDBMS before they existed all in a non tech industry career.
So when I read about Exchange Server to me it still feels quite modern.
To test our code changes, we would check out a VM that was running Microsoft Windows Server edition which was a beefy VM that was running Exchange. It was a carbon copy of the server running in production.
The Exchange code base frankly was a behemoth. No one had a full understanding of how it worked E2E. I am just sharing how I understood it. I was only a lowly L63 btw.
> The hierglyphics on the left of the dialog box are supposed to distract someone who is peering over your shoulder trying to learn your password as you type.
lmao... but is it actually random or is it a hash of your password to make sure you typed it correctly?
If was like this because it was designed before networks were expected to be fully connected at any one time. Mail would hop its way towards its destination as intermediate nodes dialed in over modem to upstreams.
Ok but why would all infra would go down everywhere, at the same time? Is it all a big server? Are there any Architects left or is it all Golf Players?
Microsoft product reliability has been a running joke since the company started launching products. Why would anything change just because they pivoted to managed services instead of shipping install media?
If it takes weeks to get some code into production, I understand how AI can enormously speed up things. Yes, AI can be fantastic but if people claim 100x increase, something else is majorly fubar.
All the MS memes today made me realize people still use Outlook?
I must live in a bubble... the last time I heard of anyone using Outlook was when Scott McNealy was calling it LookOut! in the 90s.
In a ~35 year tech career I have never been exposed to, nor used Windows nor Outlook and have never met anyone who does. Who are these companies that still use it?
A large majority of companies I've worked for over the last 30+ years used Outlook and Exchange Server, or now M$365, for email, even in those cases when my actual work was on Linux. The exception were those that used Gmail...
It's not about outlook the mailing app. They called their SaaS e-mail Outlook, you can use it without using Windows, in the same way as Gmail. Pretty popular in the corporate world
Many, many big companies do, and some universities also moved to MS365 when Google downgraded their free campus agreement, because they were already paying for MS365 for Office and that came with cloud storage and outlook.
> I must live in a bubble... the last time I heard of anyone using Outlook was when Scott McNealy was calling it LookOut! in the 90s. [...] In a ~35 year tech career I have never been exposed to, nor used Windows nor Outlook and have never met anyone who does.
Yes, then you probably at least work in a bubble.
In my experience, it's more common than GSuite in most companies outside of startups and big tech and is ubiquitous at schools, among many, many other entities.
I’ve worked at 2 companies who used Google for email and calendaring but still relied on O365 (one of the many naming incarnations) for Word, Excel, and PowerPoint. Microsoft really do have quite a mindshare foothold in the office productivity market.
Sounds like you live in the Silicon Valley bubble. I don’t have a stat but I would wager that most businesses (especially larger ones) run on outlook/exchange.
You have probably mostly worked for tech companies where business employees were not the primary workforce. When you think about it most other business generally have everyone needing a word, excel or PowerPoint. It bundles cleanly with the whole package.
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.
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.
I hope everyone involved in working on this is staying grounded and relaxed and not suffering a ton of physical stress over what is ultimately the result of greedy leadership decisions :(
Considering the middle management culture at MSFT and other tech BigCo's it's probably better that this be a huge public outage where their crappy managers will actually face some heat for creating the kinds of processes that lead to these outcomes rather than can throw the team under the bus when inevitable human error creeps into their obviously un-followable at scale over time process.
This needs to be amplified. A lot of the updates carry all the hallmarks of leadership consistently denying the engineering teams the time to build out sufficient introspective and troubleshooting tooling, on the finance-supported rationale that it is not financially justifiable for such low probability events regardless of impact. And this can be as simple as allowing for enough shadow non-Production environments real-time twinning inputs at scale enough to reproduce thundering herd issues, for example.
Take 8:52 PM UTC, for instance. "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." So many questions flow from this.
They jumped from "affected servers have become unresponsive" straight to "restarting these servers". No granular troubleshooting of a random sample of the unresponsive cohort to identify the precise origin of the failure mode. Possibly their own organizational chaos prevents the team at the low granularity layer seeing the pattern of whole groups of servers, from effectively interacting with the right team to troubleshoot at the individual server, high granularity layer. I've seen that at many of my clients; sometimes the different teams at different granularity layers don't even have established engagement channels for when things blow up across those granularity layers. I could go on, but you get the drift.
If you obsess over internal tooling, you waste time yak shaving and ship nothing; if you only care about shipping features, technical debt accumulates until a major outage hits. Because cutting corners for speed is the path of least resistance, paying down that complexity later is much harder than maintaining discipline upfront.
Everyone wants to blame the bankers and the bean counters. As I get older I realize that businesses will happily forgo insane sums in the name of predictability and continuity and that it's the team leads and the middle managers who don't want the troubleshooting and the control panels because those would provide an quasi-audit log that would more readily quantify bad management. They see these systems as a threat, a way for information of what's really happening to leak around their control.
Of course not all team leads and middle managers are like this but too many of them are and the bad ones are a great fit for exploiting BigCo environments so BigCos act like a catch basin for them.
Current status: Our investigation has found that a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests. We're preparing a configuration change to address this behavior that can be applied across all affected servers, and we're validating it on a subset of servers before applying it more broadly alongside restarts of the affected infrastructure. In parallel, we've begun reverting a recent network configuration change that correlates with the start of impact and are monitoring to determine whether this contributes to recovery.
The temporary traffic limitations we previously described are now in effect in specific locations. We're monitoring the affected servers in those locations to confirm whether they remain stable while handling a narrower set of connections, after which we'll gradually reintroduce additional traffic.
---
The list of impacted services just grew tremendously.
From the 12:56:09 AM UTC update:
Features of the Microsoft 365 services below that interact with Exchange Online and email services are impacted. Elements of those services that do not depend on interaction with Exchange Online remain functional.
- Exchange Online: Users may be unable to access their mailbox using Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (EAS), or REST-based connections, and email delivery may be delayed.
- Microsoft 365 admin center: Admins may be unable to load some admin center pages.
- Microsoft 365 apps: Users may be unable to view their recently used files.
- Microsoft 365 Apps Admin Center: Multiple services including Cloud Update, Cloud Policy, and Inventory are affected.
- Microsoft 365 Education: Features including Assignments, Reading Progress, and Speaker Progress may be impacted.
- Microsoft Copilot 365: Users may be unable to load Copilot Chat or receive responses in the web and desktop apps, and Copilot experiences may be unable to access work data such as email, calendar, and files.
- Microsoft Defender for Office 365: Safe Links may be unable to verify URLs, which may impact users clicking links in Outlook and Teams.
- Microsoft Defender XDR: Users may be unable to load Microsoft Defender portal pages or solution tabs.
- Microsoft Fabric: Users may encounter failures when exporting reports with sensitivity labels to PDF or PowerPoint, or when updating artifacts with sensitivity labels.
- Microsoft Graph: API requests that access Exchange Online data, such as mail, calendar, and contacts, may time out.
- Microsoft Intune
- Microsoft Planner: Users are experiencing Plan and Task operation reliability issues.
- Microsoft Purview: Multiple Purview services including Authorization, auto-labeling, Data Loss Prevention (DLP), Communication Compliance, and Data Classification are impacted, and users may be unable to load Microsoft Purview portal pages.
- Microsoft Teams: Scenarios that depend on Exchange Online, including calendar, meeting scheduling, and creating chats for organizations using Information Barriers, may fail. Core messaging and online meetings remain largely functional.
- Microsoft To Do: The app may not load, and users may see operation failures.
- Power BI: All users may intermittently be unable to export reports with MIP sensitivity labels to PDF in Power BI.
- SharePoint Online: Features that depend on Exchange Online may be impacted. Accessing files stored directly in SharePoint Online remains functional.
- Universal Print: Users may encounter errors submitting print jobs or using admin features.
- Windows 365: Customers who have configured their tenant and Cloud PCs to use Microsoft Purview Customer Key for Windows 365 Cloud PCs may have users who are unable to connect to their Cloud PCs.
Current status: We've reviewed known impact scenarios and have revised the list of impact services and features, which can be viewed in the "more info" section of this communication.
We're continuing our work to isolate the issue affecting server availability, as well as other workstreams.
---
So much for seeming hopeful.
From the 12:08:53 AM UTC update:
Current status: While the servers we've returned to service initially remain healthy, we've observed that they can become unresponsive again once they begin receiving traffic. We're analyzing diagnostic data from these servers with our networking and platform experts to determine what's triggering this behavior.
Building on the protective traffic management measures we've implemented, we're also temporarily limiting which types of traffic can reach the affected infrastructure in specific locations. This will help us determine whether a particular type of request is contributing to the impact and allow us to restore service incrementally. Additionally, we're rebuilding a subset of affected servers using a previous software configuration to validate whether this prevents them from becoming unresponsive, and we'll expand this approach to additional servers if we observe positive results.
---
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.
Current status: We're applying infrastructure capacity improvements where possible in an effort to help support traffic in regions coming online. We're continuing to monitor the results of changes applied so we can identify strategic actions that can help to improve service health across all affected regions.
---
Hopefulness returns.
From the 1:50:27 AM UTC update:
Current status: We're seeing positive results with our efforts to restart affected infrastructure. We're actively monitoring the performance of these to verify stability which will support improved availability. Remediation actions will be expanded as we confirm stability with the changes applied.
They've tried turning it off and back on again, now they're moving on to identifying strategic actions that can help improve service health.
This doesn't sound like hopefulness, it sounds like somebody's huffing hopium. It sounds like somebody's who's all out of ideas, but there's no direction to go but forward.
This is so true. Not making excuses for Microsoft, but OP’s at this very hard. What would have been a “reboot the server” at small scales becomes a concerted operational nightmare at larger scales.
The staging pattern doesn't scale for systems this large and complicated. Everything is constantly in flux and changing. Ive worked on systems this large and we had something we called staging but it was a joke.
Gradual rollout, pilot regions and monitoring are usually how you avoid broken stuff becoming global incidents. Will be interesting to read what process failed here next week.
It doesn't matter if large portions of the grid go down at once. See the recent Spanish outage - the coordination of bringing it back on line is an art of its own.
While I think it's a bit premature to jump to "AI is at fault", and I will emphasize that I appreciate Microsoft's transparency in their status updates, these updates do have much more of a "we don't know what's going on" feel than any other major outage I can think of.
It's been hours, and the status updates still feel like there is an undertone of frantic panic (understood if you can't determine the root cause). When I think of past major outages, they may have been down for hours but usually folks knew what the root cause was relatively early, even if remediation took some time.
I wouldn't be surprised if AI coding and release pressure was a primary cause, so I really hope the future post-mortem is made publicly available.
> I wouldn't be surprised if AI coding and release pressure was a primary cause, so I really hope the future post-mortem is made publicly available.
If nothing else, increased change volume will mean the number of candidate diffs ballooned, possible to a level where non-AI review is impossible on incident-level timescales.
Coupled with each change also being AI-documented and the relevant teams having less hands-on understanding of their own changes, so going to the pushing team and asking "Tell me about _____" isn't an option.
I think this has to do more with their calculating SLAs for uptime than anything else. Once they have a root cause and start deploying a fix they can "stop the clock" on the outage, even if they don't get to your tenant right away.
Imagine the amount of money they're losing right now in credits that will have to be applied once this finally gets resolved.
Reading the status updates feels a lot like watching some of the OpenAI models try to debug a thorny issue. Throwing half-baked solutions at the wall, then reacting in surprise when it makes things worse, getting increasingly detached from reality until someone clears the context and makes it start over.
Nah, they're just debugging a hard problem while the world looks on! The 'normal' problems they have processes to work through, but hey emergent systems and all that - they have to expect the unexpected.
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.
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.
If they rebooted it, and it started working again, would you just walk away? Or would you try to figure out why the fuck it needed to be rebooted in the first place?
Thales or Collins or Honeywell or whoever provided the system would. The technician at the airport would only follow a procedure listed on a checklist, which probably includes rebooting the system.
Ironically there have been a fair few cases of aircraft incidents where components were reported as bad by pilots but the issue couldn't be reproduced on the ground and "it worked" after a reboot and self-test so they just kept using it (with this cycle repeating multiple times). Often there were clear physical problems (cracked solder joints, stuck microswitches, broken insulation) that were only discovered after a catastrophic failure but could've been discovered with a more inquisitive engineering culture.
I would argue a "just reboot it" culture leads to more problems -- engineers should be empowered to diagnose problems before they become catastrophic. In the world of software we even have mechanisms for extracting data from failed systems to root cause them later, and yet most people do not take that step before "just reboot[ing] it".
[1]: AirAsia 8501, Lauda Air 004, and SmartLynx Estonia 9001 come to mind.
But these intermittent failures lead to delays and worse. The sheer cost of repeat events leads to action. If deferrable at all the standard troubleshooting is mostly remove and replace. The repair and reliability processes identify these rogue units fairly fast and the actual rates of that in a well functioning airline are very low.
Right, rebooting only really makes sense if you understand why the reboot is going to fix the problem. As in, corrupted volatile state is reasonably fixed with a reboot. Any hardware issues or persistent state problems could well get worse.
What makes sense for something that is used for 20 hours at a time is different from what makes sense for a service that literally has "365" in its name.
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
Yeah, a place I worked at years ago had a cron job to restart some critical service at midnight because it leaked memory all day. That was there for years.
We had a mail server that ran on an old DEC minicomputer. I rebooted it every six months because it had a slow memory, or possibly resource, leak somewhere.
It was the only thing running on that box so it wasn't a big deal to reboot.
Another real world example: to this day, it's a good idea to limit requests per PHP process using the MaxRequestsPerChild(apache)/max_requests(php-fpm) config option to some sane limit. After that configured number of requests, the PHP worker is terminated and restarted to... "fix" memory leaks. I remember setting that in the late 90s on Apache...
I've used PHP in two previous jobs and certainly the stuff that I was in control of had it set to 0 because we made sure we didn't leak memory. Other departments... I'm sure at least one had the limit set to something non-zero.
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.
~25 years ago I was a firewall administrator, and the Cisco PIX we used was notorious for gradually running out of memory, effectively cutting off the entire company from the Internet when it went down (and it was a very big company).
We absolutely should have scheduled reboots during off hours. Lessons learned.
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.
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.
I have lived through and debugged cascading failures and large scale distributed systems.
The problem is amateur hour is the entire industry. Nobody specs anything, nobody tests overload conditions, nobody thinks failure modes. The stuff that every engineer does when building anything else other than software doesn't happen. The orgs are bloated. Too many teams. Too many silos. Incentives are stacked the wrong way. People are motivated to not think about systems but stay in their lane. Responsibilities are split in weird ways.
Yes. Big systems are hard. But we can build, manage and understand big systems with the right approach and people. Even one computer is complicated and many people get stuck trying to debug a piece of software running on one machine. At the end of the day it's not magic. All of humanity is big systems but when I have a power failure the power company is generally able to understand why and resolve it and the water in my tap doesn't stop flowing and the cell towers still work (generators, who would have thunk).
A friend who is really good had to leave Microsoft because of how AI was pushed. Before that he was telling me some other stories that make the culture seem pretty not great. Heard similar stories from other people. It used to be a great place filled with great people until at some point it's just another big company.
We took some of the hardest problems in computer science: distributed systems, scale, concurrency and networking, and made them the standard for every To do app.
This is the inevitable consequence.
When I look across the scale of all the failures that have occurred in big tech over the past few years, my self-hosted solutions have been cheaper and more reliable. They are simple. They are small. They are easy to fix and diagnose. Because they're not trying to solve all the world's problems.
People expect software to be feature rich, complex and solve all the world’s problems. And if you don’t do that, the vibe coded competition will beat your cleanly architected product commercially.
It's not even better though. It doesn't have more features because it's a distributed system. It isn't faster because it's a distributed system. Maybe it has a bit higher uptime but nobody was paying too much attention to that anyway, except when it's down. And it's much better for your PR if, when it's down, it isn't down for everyone at once.
I'll be the downvoted comment, since HN doesn't like to hear this, but the other flavors of engineering do stuff we don't because they're regulated.
My bet is we'll eventually get there. Planes kill people when they fall, software used to not be as dangerous, but it's been a while since it became critical infrastructure.
I can't think of any other engineering discipline where demand might increase by a factor of a million in a few seconds because some DNS record was propagated incorrectly or something - regulation won't magically solve the issues unique to software. Maybe it's doable with vastly increased costs (a classic would be running fully redundant 1:1 warm failovers, which nobody could economically do at the cloud provider level.)
That's not to excuse incompetence or whatever, just to note that the benefit of software is precisely how easy it is to change, which will always lead to more problems.
Electrical engineering of the power grid has the exact same failure mode: cascading failures of interconnected power grids can cause loads to increase by factor of a million in a few seconds.
I remember a power outage in 2003 that knocked out power for 55 million people and took over a week to restore in many places.
Note that buggy software was a major contributing factor! The software was designed to, and would have, detected a deteriorating system an hour before anything broke, which would have provided ample time to intervene. However, a race condition caused the whole monitoring system to display stale data and then crash, including the redundant backup. This wasn't the only problem by far, but it was one layer of swiss cheese.
Also note the power companies have clear procedures to reboot the grid, known as a "black start[up]". And they test these procedures, though without taking down the grid.
Which is the kind of exceptionalism that really creates these problems. Software is the only industry that allows people untrained in running global infrastructure to run global infrastructure.
Given that people on reddit claimed that in the entirety of New Zealand no real estate transactions can be settled, causing cascading failures [1]...
I think this might actually be the incident pushing governments to designate large online services such as MS 365, Gmail et al as critical infrastructure and force companies to massive, yet-unseen levels of transparency and regulation.
The EU is already itching to act ever since the Trump admin forced US Big Tech to terminate service to the ICC judges, and this here was a square own goal for Microsoft.
The other option is to not outsource everything to the cloud. Yeah, it is more convenient ... but in these times, being a bit more self reliant is not a bad thing.
The problem is that you are only as strong as your weakest link. At some point, something somewhere will be architected poorly and it will one day line up perfectly with 2 other bugs that were incredibly hard to predict and then you're stuck in Microsoft's current situation.
Also, power grids are a poor example. There's been multiple instances of absolutely catastrophic failures so hoity toity capital E Engineers also make mistakes.
This is the same as what's been happening with entire industries: Build for the critical path. Eliminate redundancies. Eliminate resiliency. Lean staffing. Just-in-time manufacturing. Single-vendor mandates.
In the name of efficiency and profit, we have stripped away all the safeguards that should prevent cascading failures after the first domino falls. Anything that doesn't return profit now, today, every day, must be purged. Because what if that domino never falls? Then you wasted your money! Think how much you can save if you don't need to make backups! (And every dollar saved is a dollar in my pocket!) Etc.
And torben-friis is right: the only solution to this, demonstrably, is regulation. Require multiple vendors for every major component. Require staffing sufficient to cover a third the company being on vacation. Require resilient systems, that can take a single disaster and keep on trucking, because they are the backbone of our economy.
How did that AWS DNS incident go recently? Unplanned outages are unfortunate but common, and hubris is the problem when everyone assumes that they (or their pet vendor) are immune.
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.
To be fair to Microsoft (and I'm having trouble believing I just wrote that), the vast majority of everybody's outages are "self owns". If you don't change anything, you're not going to break anything, and major external events (fires, cable cuts etc) are rare and can usually be worked around.
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.
There are methods for building complex systems our of smaller pieces. Humanity has done this forever. An internal combustion engine is very complex. An airplane is very complex. You put a boundary around your system, you build it to a spec, you test it to a spec, you define the behaviour across anything you can see. When two engines fail on the airplane it can maybe still at least glide. Maybe there's an ejection seat. Because someone is doing the system thinking with some level of discipline.
A brick is very complex. A bearing is complex. A bolt and a nut and a washer are complex. An integrated circuit is complex. We build stuff out of that. Like buildings that don't fall when you sneeze on them.
In software we use duct tape - at best. But that's not just Microsoft, that's pretty much everyone. With maybe few exceptions.
Software systems are by nature more complex than physical systems. They also lack any tangible interfaces beyond code and diagrams and collective knowledge in the minds of the humans who build and maintain them.. The rapid evolution of software is no help either..if anything AI is accelerating that rapidity as well.
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.
There was an article posted by a former MS / Azure person earlier this year that described the dumpster fire of node management and their cloud control plane
Could be something adjacent - the last time I majorly blew up a release was because something had changed (which was fine) but it caused a list of items to be broken over two pages, but only in prod. Me and a team mate were scratching our heads for the longest time because "what had changed" was quite mundane itself.
The classic 'database is smaller in testing than in prod' problem which is responsible for some outages IME.
Often the 'query was not optimised but that didn't show until prod' one.
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.
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.
Microsoft is not a small startup where the CTO is getting pulled into firefighting.
They should have established procedures for large-scale events, and they must include a coordinator whose entire job is to manage the external and internal communication.
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.
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.
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.
An organization can become fundamentally opposed to the purpose for which it was created. Organizations simply don't follow the same laws as the individuals inside it do. A company can be made of geniuses and be totally ineffective; it can be full of talented go-getters and be completely unable to fix problems.
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.
That’s purely a choice by those claiming the nines. I’ve worked in companies selling software with more than 6 nines uptime (so that we can be more confident about the 5 nines). Not 4 nines uptime plus some money back for the other one.
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?
Professional hour would be invisible. Outages don't happen because they were anticipated and prevented.
You can't do much to work around nuclear war or a major asteroid strike, but keeping important things working under normal operating conditions should not be a high bar.
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.
Nadella stripped mined the company for AI jank, and everything has been falling apart. Github has been unreliable a lot lately. Xbox is basically imploding. A lot of Azure, Entra, Intune, etc. is shockingly janky, and there is clearly very little investment in it.
I read opinions like those but then I worked with Azure at previous jobs a lot and never had any really big issues. On the other side, I just tried using AWS for a small Saas of mine and after setting up SES, I got a shady email, from non-defult support amazon domain that I need to send them scans of my personal documents. Link in that email was blocked by uBlock Origin, domain was not the same as other emails, not a single notification in AWS Support Console anywhere so I ignored it as phishing. Got suspended two weeks later, not a single human in sight within 48 hours of me making a ticket, I just gave up and moved emails to Cloudflare. If I had actual real clients at that phase I'd be pretty pissed. I genuinely don't know how people blindly trust AWS with everything these days, it's 2026 and there's still not even a hard billing limit built into AWS.
Even as recently as 2022 (when I used to work there), infra-as-code use at Microsoft was still very nascent and non-standard. Infra at Microsoft was mostly "ClickOps", with a ton of tribal undocumented knowledge about the right order to do things, changing the defaults, and things like that.
The amount of times we've had to reach out to an experienced person who had transferred to another team/org about processes in our team was ridiculous.
How much of it is deployed with nondeterministic tooling, though?
I remember their customer-side push for semantically merging Office and some other suites into something-or-other like 365 or Copilot, creating enormous confusion. I have difficulty believing MSFT distinguishes between handmade and machine-learning tooling in that type of environment.
Can you clarify what you mean? Do you work there, or have you had negative experiences as a customer?
Disclosure: I work at AWS, at the core EC2 dataplane for many years now. We monitor our production environment very aggressively with tight SLAs that page us at night, and our technical leadership is competent as well.
at something AWS scale something is always on fire, they probably measure disk head crashes per second, and they're supposed to insulate it from their clients with layers of redundancy. If those layers are working, they're doing it okay.
Above those layers is a ton of jank, e.g. Elastic Beanstalk. But my understanding is the fundamentals on AWS - compute, storage, networking - are pretty much rock-solid.
I essentially said this in a sibling post whose parent asked why it seems like nobody knows the codebase anymore except my post was immediately flagged.
I think this is the logical conclusion of using copilot to write your stuff for the last two years. Nobody knows what it does and more and more bugs are being solved by just pointing the AI back to it again. Combine with the fact that so many people have been laid off and replaced with copilot I'm not surprised that the few who remain aren't quite sure how to solve it
The sales have fallen off compared to the Playstation.
A quick google search turned up these global sales numbers: PS3 87.40 million, PS4 117.20 million, PS5 96.44 million. Xbox 360 85.73 million, Xbox One 57.96 million, Xbox Series X/S 35.68 million.
Their console is no longer their primary objective though, xbox live is where it's at - tons of people did the math, why buy a console when you can get a subscription with tons of games for 3+ years for the same money instead? It's a really attractive offering for people who don't play games all that much (that is, more than 2 hours a day).
I think Sony is shooting themselves in the foot with the digital only consoles too - unless they maintain a very attractive set of exclusives at all times, people will just choose whichever digital subscription is best or cheapest for them instead of something tied to a particular console.
I think they've broken the trust with exclusives and don't think they can get it back quickly, almost all of the best PS4 exclusives that I can think of ended up on PC anyway. Exclusives won't be a factor for me when weighing up a PS6
I'm usually late in getting new console generations (didn't care for paying for new generation premium), so I remember looking to buy an Series S/X a year ago and it wasn't anywhere, there was wild speculation about a new generation or those handheld things taking over.
It seems to be back in stock now, but at a cost of about 1000 Euros for a Series/S I'm not really feeling enticed even if GTA 6 is around the corner. They probably really shot themselves in the foot by not having units out a year ago and now fewer will buy due to pricing.
Well, speaking for myself, paying the new console premium for my PS5 turned out to be a decent deal given used ones go for about the same at the moment...
Here, Series S is £400-£430 for 512GB or £500-£520 for 1TB.
Xbox Series X is £600-£620 for digital 1TB or £50 more for the disc version. That's much more than I paid for mine a year after launch (£450 I think), but luckily still nowhere near 1700 Euros.
insufficiently supervised AI on top of poorly architected sales and marketing driven decisions looks like it's a good recipe for a nice warm garbage fire
I believe it has more to do with him force-feeding Microsoft employees on A.I. resulting in slop code and outages.
If this continues the company will see a lot of customers leaving. And they were already in a bind since Europe is finally realizing that its dependence on American tech could be used against them. Luckily most European politicians are corrupt and can easily be bought to prevent them from ditching Azure and Windows.
> Luckily most European politicians are corrupt and can easily be bought to prevent them from ditching Azure and Windows.
They're not corrupt (in a lot of cases), mostly just ignorant. Like, they don't understand the tech, and microsoft is safe, they're already using it so handing over large swathes of their infra to them seems reasonable.
MS have wonderful sales people, and this is why they do well with governments and large enterprises.
There's also a co-ordination problem, in that all of your counterparties (like your citizens, for instance) are familiar with MS and therefore it costs a bunch locally to move, for little short-term reward.
This is actually a place where (good) regulation could derisk a lot of these changes, but you'd need a committed group of politicians who can convince the civil servants to keep at it. It'll happen, but slowly and in starts over the next 5-15 years.
Where does corruption start and lobbying begin? American cloud providers are hosting more than $340 billion worth of European workloads on their infrastructure, including email, videoconferencing, office documents and storage.
If they transfer this to sovereign providers it would cost Big Tech serious money. So they're quietly lobbying to slow down the speed at which European nations are moving away from them.
I literally had a person from IT tell me “Firefox is open source so it’s not secure, that’s why we have to use Edge” the other day. They are beyond hopeless.
And Microsoft is being smart by cultivating this worldview. Open source has no such thing. In general, the company with the best marketing can be expected to win the market. Product quality plays only a minor role.
Microsoft also sells contracts to companies and open source does not. If "open source" does, it's someone like Red Hat who has to take on all the legal responsibility themselves, just like Microsoft does, and that makes the product as expensive as Microsoft's, only it's not subsidized by mass surveillance so it's even more expensive.
i had a very similar experience with a co-founder and ceo.
it took half an hour to even somewhat convince them that academic/postgrad student open source projects with one commit four years ago are not the same thing as linux/ubuntu/docker/etc.
sibling makes a good point tho. what they were probably thinking was “we want to be able to blame someone who is not us if it goes wrong at some point”. that’s 90% of the microslop business pitch right there.
open source, it’s on you. microslop, it’s on them.
The only reason companies use Entra is it appears cheaper but eventually you pay as much as competitors. Okta is a way better IAM solution if you need one. Although it’s very pricey.
I am aware that the authentication subsystems have major structural problems which make finding things like exfiltration bugs in azure surprisingly common. I suspect the current incident is related. I'm hoping it's also caused by too much insufficiently supervised AI coding on poor architectural foundations, and that being caused by that will be obvious and hopefully become public. But that's just speculation on my part.
After the last couple of updates on entra, where you keep getting the "loading dots" to just pull up is insane. I still use Azure or PowerShell to do the task by the time it can "load up".
My take is the reason companies use Azure is lack of imagination. Like Service Now. Just horrible software, and thems that make the decision to buy it aren't the one's who have to use it.
Vendor lock in is always a thing really, you don't always get choice in SaaS providers and how they auth. Could of course choose another SaaS provider but then that starts reducing the pool, assuming you have alternatives.
I don't know exactly what's going on with today's outage.
But this is certainly exactly what I'd expect after indiscriminately laying off half your workers, then immediately offering a buyout to make sure any experienced people still standing will find their way to the door.
If this incident, or the difficulty they're having with remediation (update: holy shit, they still haven't even identified the problem), are somehow not caused by any of that, then it's at least a preview of what things are going to be like.
OTOH, I couldn’t manage Entra without their AI chatbot. That system is a Lovecraftian stack of sadness built upon despair, of which mortals are not meant to know.
I have the pro Microsoft copilot subscription at work just so I can search Outlook and teams since the native search doesn't turn up things when I search exact strings that are in the messages or use filters for other things like sender or recipient. Crazy to have to use an llm just to find an email
This really is the honest truth, every interaction I have with the MS platform is somehow worse than an actual dumpster fire. AI is the only thing keeping the ship afloat. Then again maybe that's the point?
Fabric is a weird one, as it's sortof a GUI over spark, but also PowerBI and lots of weird services.
It feels like a "data plaform" for people who've never used one before and only have the vaguest idea of what it means.
That being said, Spark is pretty good and we're running a lot of workflows on it (and probably building more on top, I suspect that I'll be much angrier about it in approximately 6 months or so).
Support in Europe has been nearly dismantled in favor of low cost countries. I wonder how they expect it to function now they it's basically third parties withan AI slapped on top.
You don't understand, the agents aren't fixing the outage because those human engineers didn't make the infrastructure AI first. The only possible follow-up from this is that the faulty infra needs to be completely thrown away in favor of the vibecoded replacement.
I agree. All the execs need to do is tell Copilot to "fix this so that it never happens again. Make no mistakes" and run it on bypass permissions. Tada!
So a few years ago Nadella was a God among CEOs capturing OpenAI at the right time etc..but yeah laying off thousands of tenured folks surely is great strategy, god I hate the tech industry.
Btw does everyone see how insanely crappy Windows 11 is compared to MacOS
I made the switch to Linux Mint and it’s wonderful and almost triples my battery life. I’m also in the process of switching to a phone with graphene os which runs like butter and feels so much more secure, safe and private.
It's been three months since I switched to Arch. I've had a couple of hiccups that I couldn't resolve with an agent, or that I simply didn't want to spend too much time troubleshooting. Other than that, performance has been absolutely amazing. My terminal and browser open in milliseconds, not seconds. Even the heavy system I work on builds and loads in seconds instead of minutes. If I don't like a particular configuration, I can simply ask my agent to change it. Linux is GREAT in the agent era.
Battery gains on laptops are insane. Swapped a month ago on one, still need windows stuff on the other, but same model and one last all day and one has to be plugged in each session.
and that's crazy because traditionally Linux would drain your battery faster because it was lacking all the power optimisations. It still is, but windows must've gotten so bloated it's worse now.
I tried few distros including Mint but in the end CachyOS was one that works for me best. But I still got this W11 virtual machine where I can see how the system "evolves", and it still baffles me that Microsoft has the audacity to throw message saying "Windows Update is committed to helping reduce carbon emissions" and having "Energy recommendations" that "Lower your carbon footprint" where background processes continue to drain machine resources at random intervals since W10
>>Btw does everyone see how insanely crappy Windows 11 is compared to MacOS
This is just an anecdote, but I have the exact opposite experience. I'm a C++ games developer working on Windows 11 every day and other than the micro frustrations with stupid UI, the system just works. I know I can rely on it day to day. But I was also given a MacBook last year for our iOS ports and I don't understand how anyone considers it a serious operating system for work - it's full of bugs to a point where I started using AI to work around some of them. I thought maybe MacOS 27 would fix some of them and sure it did - but then it introduced a whole bunch of new ones. As a developer it's probably the worst OS you could pick - if you hate windows for whatever reason go straight to Linux, at least you have actual control over your OS compared to MacOS where basic things like spotlight are broken and there's no way to fix them other than add to the thousands of complaints on apple forums.
> hate windows for whatever reason go straight to Linux,
Honestly, for personal machines the M series is wonderful hardware, and I have young kids so no time to tune Linux (I ran it at home for around a decade or so).
But yeah, the interface has many, many bugs.
My "favourite" (new) bug is that sometimes you can't move a window from the laptop screen to another screen. It goes away if you full screen the app, but it's bizarre to me that it made it to production.
Nadella's AI fumble is a true generational fuck up. They had OpenAI, they had complete access to GPT models before any one, they even had the first coding assistant concept.
Then due to typical clueless management and lack of taste and complete buffoonery, they just fucked it all up. I'm not complaining because I think everyone is better off, but it's just amazing to have witnessed that even when they luck out on a bet, they manage to fuck it up. Copilot started as a coding assistant, and before it could breath they destroyed the brand by shoving the name into literally everything without thinking or taste. Ignored the coding part, because that's lame, and instead focused on half assed Windows or Office apps and integrations that no one will ever use. Once claude code dominated the scene, they realized the major fuckup and tried to catch up, but it's too little too late.
> instead focused on half assed Windows or Office apps and integrations that no one will ever use.
I actually know quite a few (non-tech) people that love to use Copilot in those apps. So I'm not sure it's as big of a fuck-up as you think it is (or as I certainly used to think it is).
We need to rewire ourselves to think about things that are profitable and useful. People prefer something that's expensive and useful over something that's just expensive. For some reason though it's only the people who are making useless things who are making anything at all. Nobody else tapped into the Cybertruck market segment at all.
I'm not really sure I'm understand what you're trying to say tbh. Though tangentially what even is the Cybertruck market segment to begin with?
On profitable products though; sure as a general concept, but the rate of return, opportunity cost and market competition factor into the profitability equation too. You could go waste your time building a desktop app for a chatgpt clone and make some "profit" in the same time your competitor threw similar resources at making a claude code and that makes 100x your profit. That would mean you actually lost despite the profit. The opportunity cost isn't only in building the wrong thing, but also in the human resources you allocated to the task that deprived other areas. I see no world where the 6 dozen copilots we got from Microsoft have any good ROI beyond diluting a brand and making them more of a laughing stock.
We need to rewire ourselves to think about things that are beneficial to society as a whole. Not "profitable." Profit just means more money going from the many to the few. That's what's gotten us into this awful situation.
Crappy as in doesn't need third party full access to all accessibility untrusted toold for stuff like mouse scrolling the currect direction, volume control on external hdmi monitors, being able to navigate the UI using a keyboard, having the computer staying running when connected to a power source, etc?
One has to spend more on third party tools for getting MacOS to feature parity with a windows than a Win Pro license...
Linux is fine on the other hand, but you compared to a joke of an operating system.
It's impacting all businesses running MS hosted Outlook, that would also include companies with 100,000 of employees. It's a global issues not just one area.
Well Microsoft made everyone move to managed exchange/outlook right? I was told you can’t self host anymore. How did they not design for regional resiliency?
Is there any proof that "self hosted" is still working, wouldn't surprise me if at least part of it relies on centralised services.
In a sane world the CTOs choosing this would be held accountable. The massive global economic fragility which is created by the centralisation of society is a massive risk. Diversity is important, we see it time and time again how optimisation causes panic, from crowdstrike to microsoft. When your outsourced provider is "too big to fail", you have a problem that government needs to deal with.
I haven't had occasion to spin-up Exchange SE yet, but I've read plenty of descriptions of other admins running it. I have no reason to believe Exchange itself relies on any centralized features. "New Outlook" has been alleged to use centralized servers even when connected to an on-prem Exchange SE install, and given that it's "modern" MSFT software that wouldn't surprise me, but anybody stupid enough to use "new Outlook" gets what they deserve.
One of them has two servers on AWS behind a load balancer. That's the very least of resilience.
Another one has one server in a datacenter running their primary service on a single VM. That server had issues with RAM chips a couple of years ago that brought it down a few times. However they are not crazy. They made the choice to keep their data at home, bought reportedly good hardware, accepted there there might be consequences. They have other less beefy servers but they did not load balance their service on VMs on different servers.
I think that we can agree that this is no resilience. Is it by design as in "I want my service not to be reliable"? Of course not. Is it lack of quality in the design? Of course it is. But does it matter from the point of view of the users of the service?
I run several services on a VM, with no automation to restore them if there's a hardware issue with the VM host. (There is some resiliency: a managed datacentre, the servers have RAID, dual PSUs, dual network, etc.)
For over 10 years, this has not been a problem. We understand the risk, and know how to restore services onto a different VM host if necessary.
I think the more complex system (e.g. K8S) has problems when people don't fully understand it. We've had outages there, caused by misconfigurations or unexpected behaviour.
While it's probably true that no one specifically seeks to remove resiliency for its own sake, basically the entirety of our corporate world has, over the past several decades, been relentlessly redesigning everything in ways that remove resiliency. Because resiliency is almost inherently antithetical to efficiency. At the most fundamental level, if you want to make sure you have a backup of your data, that means you need at least 2x the amount of storage. And, of course, if you want to make sure you can operate even if a critical employee gets sick/is hit by a bus/goes on vacation, you need to hire extra employees.
You design to the needs. I have resilience in my home DNS so I have a 100% availability bounded on the home (if the home is burnt down then I'll lose DNS)
At work I designed DNS to survive the loss of a city, so again 100% uptime. The riskiest part is deploying changes, which is why the deployment doesn't run in parallel and confirms state before deployment.
Resilience isn't hard when you aren't trying to serve a billion customers. The problem is we are addicted to a "winner takes all" economy, which leads to fragility. If Tesco breaks, I can go to Sainsburys, or Aldi, or Lidl, or Iceland, or get in the car and go to Asda or Morrisons. That's diversity.
But in IT the goal is all those follow the same gartner reports and all use the "best supplier" for their backend infrastructure, and if that supplier breaks then they can't restock any supermarkets.
That's a terrible risk and needs to be stopped, not encouraged. But the individual incentives are for the CTO of each supermarket to choose what the consultants tell them. If they don't they are accountable for the choice of not using things like "industry standard".
They're still trying to find the root cause apparently. The status updates I've seen (the page seems dodgy, probably millions of people hammering it every millisecond) don't sound very optimistic as of yet.
Hey, at least they fixed the status page. A few hours earlier, it was loading a 16MB JavaScript file over 2 minutes or something. It's much faster now, though I haven't checked if that file is smaller, or just the pipe got better.
When I first saw this I commented it must be bad, but that was 4 hours ago after a whole day of "welp i guess i'm not emailing anyone and meetings are pushed.".
It's 7PM PST now and I cannot imagine how fucking on fire things must be for it to not only still be down, but basically with no real communication from what i've seen (like yes there's updates, but not the "root cause found, triaging".)
In an era where everyone's vibe coding Excel clones, this is NOT the time to be fucking up your KEY moat on a catastrophic level.
Not sure why the execs and VPs aren't asking their AI agents to triage. They've been implying they don't need engineers anymore, isn't this the best time to prove themselves right?
The last email received by my partner’s work inbox was a cheerful update from their CTO or whatever about the wonderful progress they had made by moving all employees to work primarily in OneDrive. I kind of wonder if he’s just run away since then.
Imagine how frequently this will happen when old employees take the buyout option. Coupled that with the constant layoffs, the nect decade looks promising for MSFT
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 mean, I think the teams hate can be funny sometimes, but I honestly don’t get it. I’ve used all of the BIG programs. They’re all the fucking same. I can’t point to a single thing that Teams does drastically worse than any of the other options. I think it’s just a meme.
Preface: I have zero love for Slack. It’s a thing. It’s fine. I can take or leave it.
Using Teams after being used to Slack is like going from VSCode to Eclipse. I’m sure this thing is powerful, but it looks weird, it feels weird, it moves like January molasses, and it has a million features I’m completely uninterested in. I’m sure some people get value from all the baroque. I am not one of them.
(I’d rather be using IRC and Emacs but the world has other ideas.)
Not a slack power user by any means. But went from Slack to Teams and barely noticed much of a difference. We chat when it’s small and pick up the phone when it’s not. I don’t want to automate and add plugins and whatever; I want to do my work, but occasionally that means talking with other people over chat, I type and they see it. Needs met.
I haven't used others, but can they really also not search through the history and jump *fully* to that point? In teams I have to adapt my search once I reach end of context so the context changes.
Discord gets hate for their bad search, but it's vastly superior to teams.
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.
Current status: While the servers we've returned to service initially remain healthy, we've observed that they can become unresponsive again once they begin receiving traffic. We're analyzing diagnostic data from these servers with our networking and platform experts to determine what's triggering this behavior.
Building on the protective traffic management measures we've implemented, we're also temporarily limiting which types of traffic can reach the affected infrastructure in specific locations. This will help us determine whether a particular type of request is contributing to the impact and allow us to restore service incrementally. Additionally, we're rebuilding a subset of affected servers using a previous software configuration to validate whether this prevents them from becoming unresponsive, and we'll expand this approach to additional servers if we observe positive results.
---
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 03:07:45 AM UTC update doesn't sound promising either:
Current status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
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
> 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.
But a check in or analytic counter wouldn’t stop you from receiving email. This is most likely due to Microsoft’s server (not your local computer) being the one fetching the mail.
It is normally probably more reliable; except when their server is down.
It probably is a mirror for caching purposes for the mobile app or something. It lets them control the protocol between the client and their server as well.
"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
Allegedly, It's so they can use push notifications efficiently from a central place for new mail notifications. Mobile IMAP clients cannot reliably keep a TCP connection open, due to on-device power-management and network management purposes. IMAP natively supports push-based notifications, but mobile networks make that impossible to work reliably.
Which is odd. I also have Outlook for iOS, and the accounts I add in Outlook for Windows don't automatically appear in my Outlook for iOS, even though I have the same Microsoft account logged in in both. So I don't understand how they plan to make push notifications work better for me on my iPhone by relaying my IMAP e-mail account.
When the excellent Windows 10 Mail app was deprecated and they tried to push Outlook that would work through their online services, I switched to Wino Mail (open remake of Windows 10 Mail). My email works.
I mean, I can still switch to Thunderbird anytime I want, because I use IMAP and don't yank the mail messages from my mail server. And I can still receive mail on my iPhone anyway.
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.
I’m pretty certain their desktop client applies filters server-side.
I’m pretty certain because my company’s phishing-test emails skip my filters (I assume admins have a “skip filters” toggle). Which, hilariously, makes it even easier to ensure there’s a place that contains only phishing test emails (filter all not on allow-list of domains to one place, filter all on that list to another, ta-da, the main inbox now contains only phishing test emails)
I assume they do the same thing with non-MS email if you use their client, rather than maintain two filter implementations.
Biggest data heist and most obvious US intelligence operation in human history. I can't fathom why AVs don't treat "Outlook New" as info stealer malware.
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.
Here's a theory: A network change made connection setup more expensive or forced mass reconnects, saturating the front ends’ secure-connection process. Saturated servers fail health checks and get pulled, so the survivors take more load and fail too. Every client that gets dropped reconnects, and each reconnect needs a fresh secure handshake. That is why restarted servers die as soon as traffic returns. The outage now sustains itself even with the trigger being reverted, hence the traffic blocking and staged reintroduction.
The most recent surge is likely retry amplification, partly caused by their own traffic rebalancing.
Isn’t this very similar cause to the AWS us-east-1 outage from last year. I thought I remember it being about a network change that overloaded servers, leading to a cascading failure.
They should be able to mitigate that at the border. Whatever load balancing solution is in place should just drop connections before they get to a point that can overload the system. That they haven't, or can't, makes me think it's more complicated than "it's hard to bring it back up when everyone is trying to get back in"
So i know fuck all and am basically just rubbernecking the car crash at this point, but I would've agreed however they just dropped this gem:
> Current status: As part of our ongoing efforts to advance the recoverability of our frontend servers, we’re evaluating traffic controls that can be applied to increase capacity and stability. This includes traffic optimization actions such as traffic throttling, protocol adjustments, and failover routing intended to improve stability in active regions. In parallel, were expanding internal testing to track activity within a contained environment to improve traffic monitoring and issue detection capabilities.
That...kinda reads like they're just trying it? I'm assuming there's something being missed or it's a "fuck it try it again" but I do wonder if some story is going to come out of people in the decision making seats who don't know what they're doing.
Sounds like it running correctly was the meta-stable state. Failure is actually more stable since it can reach a failed state from the ground state of simply not running.
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 biggest problem with downdetector is how they visualise their outage graphs.
The Y axes are entirely independent, and so when there's an outage for Microsoft Outlook (which peaked at ~130k reports) and you get a negligable spike in pepole who get confused and report gmail (~1k reports), the graphs all look correlated and connected.
They need to show the graphs with an absolute y-axis set by the worst outage, or scale the graphs by estimated average daily users or something.
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.
It’s not just that it’s stupid. It’s broken. It can’t handle email that is on the server and not on the machine, and they’ve configured the app to store most email only on the server.
That choice is also so stupid. Why doesn't Outlook just store the text of every single email on all devices. The stupid software needs gigabytes of storage, why can't it spend a couple of megabytes on making e-mail actually work.
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.
> 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.
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.
I know it’s not actually that easy but don’t they just have some gateway that’s rejecting 100% of requests and they very gently lower that intentional rejection percentage over time?
However, in other cases it can be more complicated. For example, if the requesters are other internal services, they might not be behind a single gateway (although you should then have other controls you can use). Other times, it is not easy to block the RIGHT requests, because it is hard to distinguish which backend services will end up being hit by a request (a single request can trigger multiple calls to multiple services).
There is also the problem of catch up - if a system in a stable state is close to max capacity, it might never have the capacity to recover from a failure even if the entire system is restored. For example, imagine a log processing system that can just barely handle the normal peak load; if you have a failure where your producers locally store logs until they can send them upstream, you will have to clear that backlog, which requires additional capacity beyond a full steady state, which you might not have.
And you never really get an opportunity to thoroughly test these failure & recovery modes until something catastrophic happens, at which point capturing detailed metrics and assessing the right sequence to perform the actions are both challenging at best.
Oh man, Yes Minister is almost too good. I was making my way through that series as well, a while back, but I think I got sidetracked by Trump winning the election and Yes Minister just seemed like the actual news.
I'll get back into it. Can't recommend it highly enough.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
This is going to bring about a huge move back to local servers and local software for offices, as many people are unable to correspond or use Microsoft software right now. I am glad I refused to move our small office to 365, even if it meant sticking with older versions. I could have probably moved everyone to Linux and open-source software, but as the tech guy in our office, I didn't want the extra workload of dealing with all the support.
This year has been terrible for outages, the European Google power outage earlier this year, the PHP stuff (although that's only tangentially related),the AWS outage in May, Cloudflare a couple times around this time last year, Salesforce.
I can tell you somewhat anecdotally that people who usually forget about this stuff are starting to notice.
> This is going to bring about a huge move back to local servers and local software for offices, as many people are unable to correspond or use Microsoft software right now
One can only hope. But I am not so sure. No one seems to want to employ a local sysadmin these days.
I've yet to see a great replacement for Excel outside of gridcraft. Things like Libre CAN do it, but there's a lot of pain, and the average excel user isn't going to get over most of those hurdles without a ton of hand holding.
> Current status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
Tbh I’ve been maybe mildly impressed by how honest the past like, 5 updates have been about changes not working / taking / resolved as expected. Would have anticipated less direct honesty for whatever reason. But also sadly comical in that I feel most engineers have been there and know the feeling, and also holy moly it’s been an issue for a while!
Maybe the execs went home, so its the lower-level people approving the updates now and they just want to get it out and get back to trying to help resolving the thing.
The forced status updates come from the idea that resolution is a linear and quantifiable process, like copying a file from here to there. The idea an issue is caused by the unknown, and the remedy is unknown, is incompatible with processes and worldviews.
Forced status updates are still good. Even if they just say "we are still working on it and attempts so far have failed" it keeps people from thinking Microsoft is just playing GTA VI instead of working on it. Managing expectations is just as important as restoring service. Sometimes (probably not with a global email service) even more important. You can get away with a lot of downtime in some services as long as you are communicating what's going on
EDIT: with the most recent one it seems they might be moving backwards …
> As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
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.
Maybe problems with the Microsoft 365 Substrate that they dont like to talk too much about, but uses Microsoft Exchange code base to store copies of data that is exposed in higher level services. Some of Teams data is stored there (you cant get at it from Exchange) but not all. It also is involved in retention and other stuff used in Purview.
My knowledge of this isnt great, but I remember being given a briefing on some of this years ago.
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.
Curious nobody allows for the possibility this all comes as result of some adversarial action on behalf of … potentially so many actors, and given the recent streak and stream of CVEs discovered with help of LLMs.
So my bet is if this is in any way AI related - perhaps the reasoning should go the other way around and is not mere dumbness of otherwise great company everyone’s buying like crazy for years now. Even my diehard Apple fans friends own MS stock.
For what it’s worth, the latest status updates from Microsoft address this concern: “At this time, we have no evidence of malicious activity associated with this incident.”
Abscence of evidence vs evidence of absence notwithstanding, it’s probably best not to overly speculate.
I think the "at this time" is important, they were probably more focused on bringing everything back rather than doing a full investigation. I'm curious about the post mortem.
> Curious nobody allows for the possibility this all comes as result of some adversarial action on behalf of … potentially so many actors, and given the recent streak and stream of CVEs discovered with help of LLMs.
Looking at MS' track record I'm confused why anyone would assume a malicious 3rd party first while Microsoft has been "trying to turn it off and on" again for hours.
> 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.
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?
> 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.
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)
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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.
I’m at a large general business trade association meeting today. It’s definitely caused a prominent buzz. The impacts of this in terms of lost productivity are pretty huge. Yes, the controller can still work on the proforma, for instance. But he cannot easily share it with outside parties. And he can’t search his email for relevant records needed for the work.
I've only ever dealt with Exchange at small scale, and even then it was fiddly. I can't imagine what it takes to fix something like this at a global scale with the world watching.
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.
"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."
I mean, either roll back your update or there is a malicious actor involved.
The 4:11 AM UTC update claims no indications of malicious activity (obviously I have no way to judge that, just copying it here):
Current status: As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
We will continue to share more information as soon as we have it, and for now we can confirm that there is no indication this is the result of malicious activity. We’ll continue to apply learnings towards remediation actions as we confirm effectiveness mitigation actions.
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 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.
Haha exactly. Common pattern all over. I'm sure they're exceptionally talented execs but they seem to have a common theme of overseeing expansions off shore which can't be a coincidence
> "Milken said earlier that if a US company replaced the US-born CEO with a CEO born in India, he buys the stock.
> The first thing they start doing is cutting US jobs and offshoring or automating them."
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.
"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."
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.
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.
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.
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...
Of course they're innocent, but many business also can't afford nor want to employ people to host something like an email service for them.
I'd rather Microsoft host it for me than have to maintain a team of people with Microsoft Exchange skills running either on a cloud environment (similar issues) or on my own infrastructure.
I for one don't miss the days of Exchange going offline or having issues and being the person having to try figure it out.
Microsoft has much better reliability than MOST companies.
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.
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 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.
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.
If the self-hosted email infrastructure goes down, roughly one company is deeply affected. When Microsoft's server goes, entire industries and governments will simultaneously be unable to conduct business as usual.
From the individual's perspective Microsoft might seem like the better choice if they can achieve higher availability, but the societal cost is so much greater when the one basket you've put all your eggs in breaks, even if everyone holding their own egg on average results in more broken eggs per year.
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.
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.
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.
> 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.
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.
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…
"While the servers we've returned to service initially remain healthy, we've observed that they can become unresponsive again once they begin receiving traffic. We're analyzing diagnostic data from these servers with our networking and platform experts to determine what's triggering this behavior."
Claude wants me to reauthenticate my session... by sending a code to my Microsoft email. Also signed up for Zoom since Teams is down... and it wants the code from my email. Suddenly I miss passwords.
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.
At this point Microsoft should just throw in the towel and replace Exchange Server with postfix or something. At least we know those tried-and-true FOSS products work.
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).
Actually it works just fine because it only uses the back end to sync between devices. I was puzzled why mine said "last synced 8h ago". Only realized why when I saw this thread.
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.
Azure communication services (ACS - transactional emails) also appears to be down. Quite amazing one thing can roll out and break so many Microsoft services at once.
>Previous status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
>Current status: As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
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...
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.
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 :)
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.
Here is my completely baseless conspiracy theory. This is a Reichstag fire event to seize control of the AI industry. We will be told that the outage was the result of a sophisticated AI enabled attack, probably involving rogue agents. Only the oligarchs will be allowed license to operate AI for “national security” reasons. Jensen Huang being taken off the board is just too convenient of timing.
'In October 2026, Microsoft announced a Voluntary Exit Offer (VEO) making approximately 27% of its global workforce...'
So..
> Be the last standing SRE at Micro$slop
> Your mentors have all left, taking the exit payout, now your days are the best b/c you answer to nobody and can hide in your mountain of markdown.
> You knew each of the 7 different products named CoPilot are used to monitor your performance. So you set them all up talking to eachother, burning tokens and API limits.
> You are team top performer now, you get all the important decisions now
> You walk in the office this morning, CISA is sitting at your desk, with CVE-2026-124194 on your whiteboard
> 'You have a patch for this right, China is actively exploiting our Defense primes..'?
> Oh no, I haven't landed a patch in prod since my mentor left (because he actually did most of the work)
> Oh well, must be close enough, LGTM, CISA seems upset so better just yeet this to prod...
> ...
inb4 this is more accurate than anyone wants it to be.
Since you posted a link to my local public broadcaster, I wanted to point this out:
> [Home Affairs Minister Tony Burke] says the government has activated a digital resilience agreement with Microsoft today to ensure Australia gets priority:
> "That agreement has in fact been activated today to make sure that we get appropriate prioritisation of Australian interests in this across everything.
It's a little pathetic-seeming to plead for special treatment from Microsoft. I get Australia is an important strategic alliance* for the US, but unless these resiliency agreements are rare... what meaningful prioritisation of "Australian interests" can we expect from MS?
*a useful staging ground to field subs into the South Pacific and Indian Ocean
This complexity and lack of MS to find the root of their own problems reminds me of when spacex had a falcon 9 blow up on the pad and it took a lot of intense investigation as there really seemed to be no trigger. They even suspected a shooter. I think it ultimately ended up being due to odd behaviors with super cooled helium.
Or maybe ai broke containment and it’s doing this for the lulz.
The cognitive dissonance is infuriating.
We're automating all and every software job, then this BS happens, and they're out for almost a day.
Where are all the agents that would work without breaks to fix this is no time.
Bunch of AI-psychotic CEOs ruining all that's been built so far.
Disgusting.
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.)
421 4.3.2 The maximum number of concurrent connections per resource forest has exceeded a limit, closing transmission channel. xyzxyzxyz.outlook.com. PRX8 [Name=InboundProxyTrackingAgent][AGT=IPT][MxId=xyzxyzxyz] [xyzxyzxyz.ausprd01.prod.outlook.com 2026-11-13T01:08:15.373Z xyzxyzxyz]
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]
It won't actually bounce until either gmail gives up on its retries (which generally is 24 hours) or the outlook server gives an explicit rejection (rather than a temporary error or timeout)
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)
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.
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.
Without digging into it, I don't understand how people can run "multi-cloud" while using the most valuable IaaS that each provider gives - serverless.
Maybe if people are spinning up simple VMs and VPCs they can manage multicloud through a hub, but if you're using the big three for what they're meant for, you're using cloud DBs, API gateways, lambdas, and whatnot. With how much tuning, billing monitoring and specific configuration is needed, it seems like that'd be a hard thing to abstract. Even using an abstraction like Terraform to try to keep out of the weeds takes a lot of work, from what I remember five years ago.
Yes, and that's exactly why all the services offer more than simple VM/container hosting. They want you and push you to use all the other stuff that traps you within their moat. The last thing they want is for a competing service to be an easy substitute.
Note that the infra for M365, Azure etc is different. They would be running on servers hosted in MSFT DCs but have completely different CI/CD pipelines. M365 services have their own deployment pipelines and it takes on the order of weeks to deploy your changes to production.
Considering the fact that Outlook is down, clearly email doesn’t seem to be working. So email uses something called Microsoft Exchange Server, there used to be an on-premises version of this but MS stopped supporting it to run the cloud version hereby called M365. Email is one big “macro-service”, if you’re running Windows Server, look at the process called “EdgeTransport.exe” this is responsible for sending/receiving email on Windows Servers. There are probably multiple 100s of services supported by 100s of teams that are run while email is routed from sender to receiver via MSFT Exchange servers. My recollection is that even if one of these services goes down or introduces latency in the pipeline, it caused a major incident. When I was working in M365 Security in 2024, this Exchange Server pipeline was called “legacy” because it’s one big .NET Framework service. I don’t know if they upgraded to .NET core but developing on this was as HN comments say, very janky.
The reason Teams doesn’t seem to be down is that Teams services are completely different and are written using .NET Core and have their own separate release pipeline. It was much easier to interact with Teams services. I actually worked closely with the team that was responsible for ingesting Teams messages to the customer’s data store. Their code base was much more modern and easy to understand. Exchange Server not so much.
I don’t know if what I said is accurate but know that Exchange server code was like a fossil that didn’t change as much, over the ~5 years I worked on it from 2019-2024.
Story time over.
On-premises Exchange is still supported and licensed. It's a subscription instead of a perpetual license.
> I don’t know if what I said is accurate but know that Exchange server code was like a fossil that didn’t change as much, over the ~5 years I worked on it from 2019-2024.
Exchange is a mature product (albeit not without its flaws). Its era of change was between its 2007 and 2013 versions (inclusive) when it was made more modular and many parts were ported to the .NET runtime. The 2016, 2019, and now Subscription Edition codebases were more of an evolution and has much less churn.
"Microsoft Teams: Most of the core functionality including joining calls, meetings, group chats, and channel messages are not impacted. Scenarios that depend on Exchange Online, including Calendar related failures with scheduling, invites, viewing, and meeting edits. Creation of Live or Virtual events fail. Failures with Copilot responses for outlook, calendar, or M365 files, read history, or adding to new chats. Navigating to App chats, adding new contacts or syncing contacts in settings fail. Standard channels are working fine but users may experience the inability to create or delete private or shared channels."
I work at a fortune 500 company and they got me, 3 hours after I started working , the basic info about the obvious the internet is already screaming at you.
Since we are responsible for a large web application I tried to reach out to people through VIVA (yes, we only make use of that) and we managed only to reach about 2-3% of the user base. Information-wise it's like a blackout. For living in 2026 this is completely unacceptable.
That itself wouldn't be a problem - email is very decentralised.
The problem is that we thought that putting like 2 companies in charge of most email communication is a good idea.
Is this what it feels like to be old?
So when I read about Exchange Server to me it still feels quite modern.
The Exchange code base frankly was a behemoth. No one had a full understanding of how it worked E2E. I am just sharing how I understood it. I was only a lowly L63 btw.
As an aside, I worked on Lotus Domino—IBM's competitor to MS Exchange—before it was sold it off in 2018.
Oh, the memories. That login screen with the changing hieroglyphics [1] is forever burned into my mind.
[1] https://web.archive.org/web/20080220070921/http://lotusnotes...
lmao... but is it actually random or is it a hash of your password to make sure you typed it correctly?
I remember people phoning to say "I"ve sent you an email, press the manual refresh button to get it faster".
up to this day I ask if companies use Lotus and those who remember just shake their heads
If you want immediate response use IRC or actually phone someone.
After many enterprise customers refused to migrate Exchange Server SE exists since 2025 and will be supported until at least 2035.
Though given how the quality of their updates are going one could still say that it's "not supported", but at least they are charging money for it!
The latter is probably the case for most enterprises.
Getting releases deployed into the testing environments, much less production, requires coordination, testing, reports and sign-offs.
Of course this can normally be expedited or bypassed for incident management and critical fixes.
I must live in a bubble... the last time I heard of anyone using Outlook was when Scott McNealy was calling it LookOut! in the 90s.
In a ~35 year tech career I have never been exposed to, nor used Windows nor Outlook and have never met anyone who does. Who are these companies that still use it?
Yes, then you probably at least work in a bubble.
In my experience, it's more common than GSuite in most companies outside of startups and big tech and is ubiquitous at schools, among many, many other entities.
I'm assuming your "surprise" isn't genuine.
You have probably mostly worked for tech companies where business employees were not the primary workforce. When you think about it most other business generally have everyone needing a word, excel or PowerPoint. It bundles cleanly with the whole package.
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.
The issue now is fixing this so status of what happens is needed and not how it happened in the first place.
The cause will ans should only be published when the issue is fixed and reviewed.
Perhaps more accurate in our world.
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.
Take 8:52 PM UTC, for instance. "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." So many questions flow from this.
They jumped from "affected servers have become unresponsive" straight to "restarting these servers". No granular troubleshooting of a random sample of the unresponsive cohort to identify the precise origin of the failure mode. Possibly their own organizational chaos prevents the team at the low granularity layer seeing the pattern of whole groups of servers, from effectively interacting with the right team to troubleshoot at the individual server, high granularity layer. I've seen that at many of my clients; sometimes the different teams at different granularity layers don't even have established engagement channels for when things blow up across those granularity layers. I could go on, but you get the drift.
If you obsess over internal tooling, you waste time yak shaving and ship nothing; if you only care about shipping features, technical debt accumulates until a major outage hits. Because cutting corners for speed is the path of least resistance, paying down that complexity later is much harder than maintaining discipline upfront.
Of course not all team leads and middle managers are like this but too many of them are and the bad ones are a great fit for exploiting BigCo environments so BigCos act like a catch basin for them.
From the 1:06:17 AM UTC update:
Current status: Our investigation has found that a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests. We're preparing a configuration change to address this behavior that can be applied across all affected servers, and we're validating it on a subset of servers before applying it more broadly alongside restarts of the affected infrastructure. In parallel, we've begun reverting a recent network configuration change that correlates with the start of impact and are monitoring to determine whether this contributes to recovery.
The temporary traffic limitations we previously described are now in effect in specific locations. We're monitoring the affected servers in those locations to confirm whether they remain stable while handling a narrower set of connections, after which we'll gradually reintroduce additional traffic.
---
The list of impacted services just grew tremendously.
From the 12:56:09 AM UTC update:
Features of the Microsoft 365 services below that interact with Exchange Online and email services are impacted. Elements of those services that do not depend on interaction with Exchange Online remain functional.
- Exchange Online: Users may be unable to access their mailbox using Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (EAS), or REST-based connections, and email delivery may be delayed.
- Microsoft 365 admin center: Admins may be unable to load some admin center pages.
- Microsoft 365 apps: Users may be unable to view their recently used files.
- Microsoft 365 Apps Admin Center: Multiple services including Cloud Update, Cloud Policy, and Inventory are affected.
- Microsoft 365 Education: Features including Assignments, Reading Progress, and Speaker Progress may be impacted.
- Microsoft Copilot 365: Users may be unable to load Copilot Chat or receive responses in the web and desktop apps, and Copilot experiences may be unable to access work data such as email, calendar, and files.
- Microsoft Defender for Office 365: Safe Links may be unable to verify URLs, which may impact users clicking links in Outlook and Teams.
- Microsoft Defender XDR: Users may be unable to load Microsoft Defender portal pages or solution tabs.
- Microsoft Fabric: Users may encounter failures when exporting reports with sensitivity labels to PDF or PowerPoint, or when updating artifacts with sensitivity labels.
- Microsoft Graph: API requests that access Exchange Online data, such as mail, calendar, and contacts, may time out.
- Microsoft Intune
- Microsoft Planner: Users are experiencing Plan and Task operation reliability issues.
- Microsoft Purview: Multiple Purview services including Authorization, auto-labeling, Data Loss Prevention (DLP), Communication Compliance, and Data Classification are impacted, and users may be unable to load Microsoft Purview portal pages.
- Microsoft Teams: Scenarios that depend on Exchange Online, including calendar, meeting scheduling, and creating chats for organizations using Information Barriers, may fail. Core messaging and online meetings remain largely functional.
- Microsoft To Do: The app may not load, and users may see operation failures.
- Power BI: All users may intermittently be unable to export reports with MIP sensitivity labels to PDF in Power BI.
- SharePoint Online: Features that depend on Exchange Online may be impacted. Accessing files stored directly in SharePoint Online remains functional.
- Universal Print: Users may encounter errors submitting print jobs or using admin features.
- Windows 365: Customers who have configured their tenant and Cloud PCs to use Microsoft Purview Customer Key for Windows 365 Cloud PCs may have users who are unable to connect to their Cloud PCs.
Current status: We've reviewed known impact scenarios and have revised the list of impact services and features, which can be viewed in the "more info" section of this communication.
We're continuing our work to isolate the issue affecting server availability, as well as other workstreams.
---
So much for seeming hopeful.
From the 12:08:53 AM UTC update:
Current status: While the servers we've returned to service initially remain healthy, we've observed that they can become unresponsive again once they begin receiving traffic. We're analyzing diagnostic data from these servers with our networking and platform experts to determine what's triggering this behavior.
Building on the protective traffic management measures we've implemented, we're also temporarily limiting which types of traffic can reach the affected infrastructure in specific locations. This will help us determine whether a particular type of request is contributing to the impact and allow us to restore service incrementally. Additionally, we're rebuilding a subset of affected servers using a previous software configuration to validate whether this prevents them from becoming unresponsive, and we'll expand this approach to additional servers if we observe positive results.
---
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.
From the 2:14:51 AM UTC update:
Current status: We're applying infrastructure capacity improvements where possible in an effort to help support traffic in regions coming online. We're continuing to monitor the results of changes applied so we can identify strategic actions that can help to improve service health across all affected regions.
---
Hopefulness returns.
From the 1:50:27 AM UTC update:
Current status: We're seeing positive results with our efforts to restart affected infrastructure. We're actively monitoring the performance of these to verify stability which will support improved availability. Remediation actions will be expanded as we confirm stability with the changes applied.
This doesn't sound like hopefulness, it sounds like somebody's huffing hopium. It sounds like somebody's who's all out of ideas, but there's no direction to go but forward.
They then deliberately loadtest it to failure and check it can be bought back under control.
Gradual rollout, pilot regions and monitoring are usually how you avoid broken stuff becoming global incidents. Will be interesting to read what process failed here next week.
It's been hours, and the status updates still feel like there is an undertone of frantic panic (understood if you can't determine the root cause). When I think of past major outages, they may have been down for hours but usually folks knew what the root cause was relatively early, even if remediation took some time.
I wouldn't be surprised if AI coding and release pressure was a primary cause, so I really hope the future post-mortem is made publicly available.
If nothing else, increased change volume will mean the number of candidate diffs ballooned, possible to a level where non-AI review is impossible on incident-level timescales.
Coupled with each change also being AI-documented and the relevant teams having less hands-on understanding of their own changes, so going to the pushing team and asking "Tell me about _____" isn't an option.
Imagine the amount of money they're losing right now in credits that will have to be applied once this finally gets resolved.
Richard Cook wrote about this years ago, and it's always going to be relevant:
https://highscalability.com/designing-for-resiliency-will-be...
https://how.complexsystems.fail/
But with AI, now we can have systems that no one has understood ever.
https://americanliterature.com/author/em-forster/novella/the...
Reddit-level speculation.
I feel for those stuck in there. The outage going on for this long has got to be fucking brutal.
I would argue a "just reboot it" culture leads to more problems -- engineers should be empowered to diagnose problems before they become catastrophic. In the world of software we even have mechanisms for extracting data from failed systems to root cause them later, and yet most people do not take that step before "just reboot[ing] it".
[1]: AirAsia 8501, Lauda Air 004, and SmartLynx Estonia 9001 come to mind.
A physicist, an engineer, and a computer programmer are driving down a steep mountain pass when the car’s brakes fail.
The car speeds out of control around sharp turns, nearly flying off the edge before they miraculously manage to skid to a stop at the bottom.
Shaken up, they discuss what to do next:
• The physicist says: "We need to calculate the friction coefficients in the brake pads and model the temperature rise to figure out why they failed."
• The engineer says: "I have a few tools in the trunk. I’ll take a look underneath and see if I can fix the mechanical failure."
• The programmer says: "Why don't we get back in and see if it's reproducible?"
looks at the Boeing 787
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
It was the only thing running on that box so it wasn't a big deal to reboot.
I am happy to no longer use PHP for anything.
I've used PHP in two previous jobs and certainly the stuff that I was in control of had it set to 0 because we made sure we didn't leak memory. Other departments... I'm sure at least one had the limit set to something non-zero.
We absolutely should have scheduled reboots during off hours. Lessons learned.
we "bounce" the servers when on calls with customers.
In retrospect, the cause and cure are obvious to everyone.
The problem is amateur hour is the entire industry. Nobody specs anything, nobody tests overload conditions, nobody thinks failure modes. The stuff that every engineer does when building anything else other than software doesn't happen. The orgs are bloated. Too many teams. Too many silos. Incentives are stacked the wrong way. People are motivated to not think about systems but stay in their lane. Responsibilities are split in weird ways.
Yes. Big systems are hard. But we can build, manage and understand big systems with the right approach and people. Even one computer is complicated and many people get stuck trying to debug a piece of software running on one machine. At the end of the day it's not magic. All of humanity is big systems but when I have a power failure the power company is generally able to understand why and resolve it and the water in my tap doesn't stop flowing and the cell towers still work (generators, who would have thunk).
A friend who is really good had to leave Microsoft because of how AI was pushed. Before that he was telling me some other stories that make the culture seem pretty not great. Heard similar stories from other people. It used to be a great place filled with great people until at some point it's just another big company.
This is the inevitable consequence.
When I look across the scale of all the failures that have occurred in big tech over the past few years, my self-hosted solutions have been cheaper and more reliable. They are simple. They are small. They are easy to fix and diagnose. Because they're not trying to solve all the world's problems.
My bet is we'll eventually get there. Planes kill people when they fall, software used to not be as dangerous, but it's been a while since it became critical infrastructure.
That's not to excuse incompetence or whatever, just to note that the benefit of software is precisely how easy it is to change, which will always lead to more problems.
I remember a power outage in 2003 that knocked out power for 55 million people and took over a week to restore in many places.
Note that buggy software was a major contributing factor! The software was designed to, and would have, detected a deteriorating system an hour before anything broke, which would have provided ample time to intervene. However, a race condition caused the whole monitoring system to display stale data and then crash, including the redundant backup. This wasn't the only problem by far, but it was one layer of swiss cheese.
Also note the power companies have clear procedures to reboot the grid, known as a "black start[up]". And they test these procedures, though without taking down the grid.
Until the cost is mentioned. People love free or nearly free software.
Given that people on reddit claimed that in the entirety of New Zealand no real estate transactions can be settled, causing cascading failures [1]...
I think this might actually be the incident pushing governments to designate large online services such as MS 365, Gmail et al as critical infrastructure and force companies to massive, yet-unseen levels of transparency and regulation.
The EU is already itching to act ever since the Trump admin forced US Big Tech to terminate service to the ICC judges, and this here was a square own goal for Microsoft.
[1] https://www.reddit.com/r/sysadmin/comments/1xus565/comment/1...
Also, power grids are a poor example. There's been multiple instances of absolutely catastrophic failures so hoity toity capital E Engineers also make mistakes.
https://en.wikipedia.org/wiki/2025_Iberian_Peninsula_blackou...
https://en.wikipedia.org/wiki/Northeast_blackout_of_2003
In the name of efficiency and profit, we have stripped away all the safeguards that should prevent cascading failures after the first domino falls. Anything that doesn't return profit now, today, every day, must be purged. Because what if that domino never falls? Then you wasted your money! Think how much you can save if you don't need to make backups! (And every dollar saved is a dollar in my pocket!) Etc.
And torben-friis is right: the only solution to this, demonstrably, is regulation. Require multiple vendors for every major component. Require staffing sufficient to cover a third the company being on vacation. Require resilient systems, that can take a single disaster and keep on trucking, because they are the backbone of our economy.
Plenty of internal accounts from previous employees highlight this.
Most of the time we get demonized by resume-driven developers job-hopping every few years (seems like the lack of deep expertise is working out). Today we get to laugh at their expense. These problems were entirely foreseeable and avoidable.
If we could see the memory bits and the CPU internals, I think it would be good candidate, particularly branching and branch prediction.
A brick is very complex. A bearing is complex. A bolt and a nut and a washer are complex. An integrated circuit is complex. We build stuff out of that. Like buildings that don't fall when you sneeze on them.
In software we use duct tape - at best. But that's not just Microsoft, that's pretty much everyone. With maybe few exceptions.
What a great phrase!, can I use that in conversation?
They still don't know why this "core process" is maxing out the processor for no reason.
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
HN discussion - https://news.ycombinator.com/item?id=47616242
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.
They should have established procedures for large-scale events, and they must include a coordinator whose entire job is to manage the external and internal communication.
Actual tech write-ups can come later.
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.
Isn't that comment saying the direct opposite? If it's a cultural problem, its precisely Satya's fault for not fixing it; that's the executives' job.
Almost certainly not the fault of individual people, it's a management failure of course
lots of nines means not having significant downtime. we passed 99.99% hours ago, and we're on the way to 99.9%
They transformed Windows from a useful OS to a banal surveillance and advertising platform.
I agree there are many talented people at Microsoft, but I don’t see the professionalism in this incident.
Between breakfast, 1-hour lunch, 15-min ice cream break, 30-mins chill, 30-mins foosball games I think she worked 4 hours max.
At that point she caught some flak since it was timed with the layoffs. And I get that is not necessarily representative of the MS culture…
… but talk about timing and poor choices!
I'm sure it's more complicated than that.... but from my POV, which is extremely limited and informed by what others online tell me.... that this is amateur hour
What would it take for it to be professional hour?
You can't do much to work around nuclear war or a major asteroid strike, but keeping important things working under normal operating conditions should not be a high bar.
We use Azure at work and it’s wild how much stuff is just manual labor behind the scenes on their platform.
Seems like it’s always on fire somewhere, ripe for burnout and MBOs aren’t aligned with reality from what I hear.
The amount of times we've had to reach out to an experienced person who had transferred to another team/org about processes in our team was ridiculous.
I remember their customer-side push for semantically merging Office and some other suites into something-or-other like 365 or Copilot, creating enormous confusion. I have difficulty believing MSFT distinguishes between handmade and machine-learning tooling in that type of environment.
(Although I like the idea of Management BuyOut, too.)
AWS is no different. Everything is on fire all the time, but customers usually don't notice.
Disclosure: I work at AWS, at the core EC2 dataplane for many years now. We monitor our production environment very aggressively with tight SLAs that page us at night, and our technical leadership is competent as well.
Above those layers is a ton of jank, e.g. Elastic Beanstalk. But my understanding is the fundamentals on AWS - compute, storage, networking - are pretty much rock-solid.
Vibe coding has enabled unconscientious developers to pollute otherwise good codebases with a lot of sloppy code.
I think this is the logical conclusion of using copilot to write your stuff for the last two years. Nobody knows what it does and more and more bugs are being solved by just pointing the AI back to it again. Combine with the fact that so many people have been laid off and replaced with copilot I'm not surprised that the few who remain aren't quite sure how to solve it
A quick google search turned up these global sales numbers: PS3 87.40 million, PS4 117.20 million, PS5 96.44 million. Xbox 360 85.73 million, Xbox One 57.96 million, Xbox Series X/S 35.68 million.
I think Sony is shooting themselves in the foot with the digital only consoles too - unless they maintain a very attractive set of exclusives at all times, people will just choose whichever digital subscription is best or cheapest for them instead of something tied to a particular console.
It seems to be back in stock now, but at a cost of about 1000 Euros for a Series/S I'm not really feeling enticed even if GTA 6 is around the corner. They probably really shot themselves in the foot by not having units out a year ago and now fewer will buy due to pricing.
Indeed you’re seeing the consequences of their past decade+ of management
New Xbox to cost $1200-$1800.
Gamepass limited to 15 hours a month for Ultimate.
New Xbox cost is not confirmed.
It works perfectly on a fast home connection over ethernet, mind blowing how responsive it is and load times are non existent.
But as far as I can tell most people subscribe to game pass anyway? Why buy the hardware at all when I can just cloud game in the same subscription. .
Here, Series S is £400-£430 for 512GB or £500-£520 for 1TB.
Xbox Series X is £600-£620 for digital 1TB or £50 more for the disc version. That's much more than I paid for mine a year after launch (£450 I think), but luckily still nowhere near 1700 Euros.
This absolutely predates AI.
If this continues the company will see a lot of customers leaving. And they were already in a bind since Europe is finally realizing that its dependence on American tech could be used against them. Luckily most European politicians are corrupt and can easily be bought to prevent them from ditching Azure and Windows.
They're not corrupt (in a lot of cases), mostly just ignorant. Like, they don't understand the tech, and microsoft is safe, they're already using it so handing over large swathes of their infra to them seems reasonable.
MS have wonderful sales people, and this is why they do well with governments and large enterprises.
There's also a co-ordination problem, in that all of your counterparties (like your citizens, for instance) are familiar with MS and therefore it costs a bunch locally to move, for little short-term reward.
This is actually a place where (good) regulation could derisk a lot of these changes, but you'd need a committed group of politicians who can convince the civil servants to keep at it. It'll happen, but slowly and in starts over the next 5-15 years.
If they transfer this to sovereign providers it would cost Big Tech serious money. So they're quietly lobbying to slow down the speed at which European nations are moving away from them.
Microsoft also sells contracts to companies and open source does not. If "open source" does, it's someone like Red Hat who has to take on all the legal responsibility themselves, just like Microsoft does, and that makes the product as expensive as Microsoft's, only it's not subsidized by mass surveillance so it's even more expensive.
it took half an hour to even somewhat convince them that academic/postgrad student open source projects with one commit four years ago are not the same thing as linux/ubuntu/docker/etc.
sibling makes a good point tho. what they were probably thinking was “we want to be able to blame someone who is not us if it goes wrong at some point”. that’s 90% of the microslop business pitch right there.
open source, it’s on you. microslop, it’s on them.
Ui is clunky, they are terribly slow.
The only reason companies use Entra is it appears cheaper but eventually you pay as much as competitors. Okta is a way better IAM solution if you need one. Although it’s very pricey.
Yeah, and additionally if all your counterparties are on it, you can externalise your internal tools onto them relatively easily.
This mostly doesn't work, but it's a beautiful dream for executives.
But this is certainly exactly what I'd expect after indiscriminately laying off half your workers, then immediately offering a buyout to make sure any experienced people still standing will find their way to the door.
If this incident, or the difficulty they're having with remediation (update: holy shit, they still haven't even identified the problem), are somehow not caused by any of that, then it's at least a preview of what things are going to be like.
What changed is the productivity per employee: 2021-2026: +60% 2024-2026: +38%
To be honest, I also assumed your take on this at first. But after a bit of research I found quite a different reality!
I see what you did there.
Fabric is a weird one, as it's sortof a GUI over spark, but also PowerBI and lots of weird services.
It feels like a "data plaform" for people who've never used one before and only have the vaguest idea of what it means.
That being said, Spark is pretty good and we're running a lot of workflows on it (and probably building more on top, I suspect that I'll be much angrier about it in approximately 6 months or so).
Maybe they can use azure hosted openai models? Or are they down as well?
Just was a perfect opportunity to showcase astra and fable and other models
I agree. All the execs need to do is tell Copilot to "fix this so that it never happens again. Make no mistakes" and run it on bypass permissions. Tada!
Btw does everyone see how insanely crappy Windows 11 is compared to MacOS
This is just an anecdote, but I have the exact opposite experience. I'm a C++ games developer working on Windows 11 every day and other than the micro frustrations with stupid UI, the system just works. I know I can rely on it day to day. But I was also given a MacBook last year for our iOS ports and I don't understand how anyone considers it a serious operating system for work - it's full of bugs to a point where I started using AI to work around some of them. I thought maybe MacOS 27 would fix some of them and sure it did - but then it introduced a whole bunch of new ones. As a developer it's probably the worst OS you could pick - if you hate windows for whatever reason go straight to Linux, at least you have actual control over your OS compared to MacOS where basic things like spotlight are broken and there's no way to fix them other than add to the thousands of complaints on apple forums.
Honestly, for personal machines the M series is wonderful hardware, and I have young kids so no time to tune Linux (I ran it at home for around a decade or so).
But yeah, the interface has many, many bugs.
My "favourite" (new) bug is that sometimes you can't move a window from the laptop screen to another screen. It goes away if you full screen the app, but it's bizarre to me that it made it to production.
Then due to typical clueless management and lack of taste and complete buffoonery, they just fucked it all up. I'm not complaining because I think everyone is better off, but it's just amazing to have witnessed that even when they luck out on a bet, they manage to fuck it up. Copilot started as a coding assistant, and before it could breath they destroyed the brand by shoving the name into literally everything without thinking or taste. Ignored the coding part, because that's lame, and instead focused on half assed Windows or Office apps and integrations that no one will ever use. Once claude code dominated the scene, they realized the major fuckup and tried to catch up, but it's too little too late.
Again, not complaining really.
I actually know quite a few (non-tech) people that love to use Copilot in those apps. So I'm not sure it's as big of a fuck-up as you think it is (or as I certainly used to think it is).
On profitable products though; sure as a general concept, but the rate of return, opportunity cost and market competition factor into the profitability equation too. You could go waste your time building a desktop app for a chatgpt clone and make some "profit" in the same time your competitor threw similar resources at making a claude code and that makes 100x your profit. That would mean you actually lost despite the profit. The opportunity cost isn't only in building the wrong thing, but also in the human resources you allocated to the task that deprived other areas. I see no world where the 6 dozen copilots we got from Microsoft have any good ROI beyond diluting a brand and making them more of a laughing stock.
We need to rewire ourselves to think about things that are beneficial to society as a whole. Not "profitable." Profit just means more money going from the many to the few. That's what's gotten us into this awful situation.
One has to spend more on third party tools for getting MacOS to feature parity with a windows than a Win Pro license...
Linux is fine on the other hand, but you compared to a joke of an operating system.
Issues that cause outages are complex and can cascade across multiple areas around the world.
Designing for resiliency doesn't mean you won't ever have a major outage.
In a sane world the CTOs choosing this would be held accountable. The massive global economic fragility which is created by the centralisation of society is a massive risk. Diversity is important, we see it time and time again how optimisation causes panic, from crowdstrike to microsoft. When your outsourced provider is "too big to fail", you have a problem that government needs to deal with.
One of them has two servers on AWS behind a load balancer. That's the very least of resilience.
Another one has one server in a datacenter running their primary service on a single VM. That server had issues with RAM chips a couple of years ago that brought it down a few times. However they are not crazy. They made the choice to keep their data at home, bought reportedly good hardware, accepted there there might be consequences. They have other less beefy servers but they did not load balance their service on VMs on different servers.
I think that we can agree that this is no resilience. Is it by design as in "I want my service not to be reliable"? Of course not. Is it lack of quality in the design? Of course it is. But does it matter from the point of view of the users of the service?
For over 10 years, this has not been a problem. We understand the risk, and know how to restore services onto a different VM host if necessary.
I think the more complex system (e.g. K8S) has problems when people don't fully understand it. We've had outages there, caused by misconfigurations or unexpected behaviour.
And that's anathema to companies nowadays.
At work I designed DNS to survive the loss of a city, so again 100% uptime. The riskiest part is deploying changes, which is why the deployment doesn't run in parallel and confirms state before deployment.
Resilience isn't hard when you aren't trying to serve a billion customers. The problem is we are addicted to a "winner takes all" economy, which leads to fragility. If Tesco breaks, I can go to Sainsburys, or Aldi, or Lidl, or Iceland, or get in the car and go to Asda or Morrisons. That's diversity.
But in IT the goal is all those follow the same gartner reports and all use the "best supplier" for their backend infrastructure, and if that supplier breaks then they can't restock any supermarkets.
That's a terrible risk and needs to be stopped, not encouraged. But the individual incentives are for the CTO of each supermarket to choose what the consultants tell them. If they don't they are accountable for the choice of not using things like "industry standard".
Best of luck to those oncall.
It's 7PM PST now and I cannot imagine how fucking on fire things must be for it to not only still be down, but basically with no real communication from what i've seen (like yes there's updates, but not the "root cause found, triaging".)
In an era where everyone's vibe coding Excel clones, this is NOT the time to be fucking up your KEY moat on a catastrophic level.
Edit- Yeeeup still very vague translations of "fuck fuck fuck fuck fuck nope fuck fuck fuck"
Everyone has occasional outages but this is the worst 365 outage our org has seen since starting with M365 in 2019.
https://redmondmag.com/articles/2018/09/11/microsoft-explain...
I think it does _too much_ and the performance is _bad_ but it’s rock-solid for video and audio calls - more than even FaceTime or analog calls.
Using Teams after being used to Slack is like going from VSCode to Eclipse. I’m sure this thing is powerful, but it looks weird, it feels weird, it moves like January molasses, and it has a million features I’m completely uninterested in. I’m sure some people get value from all the baroque. I am not one of them.
(I’d rather be using IRC and Emacs but the world has other ideas.)
Discord gets hate for their bad search, but it's vastly superior to teams.
Truly, we are in dark times.
"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...
> 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.
Current status: While the servers we've returned to service initially remain healthy, we've observed that they can become unresponsive again once they begin receiving traffic. We're analyzing diagnostic data from these servers with our networking and platform experts to determine what's triggering this behavior.
Building on the protective traffic management measures we've implemented, we're also temporarily limiting which types of traffic can reach the affected infrastructure in specific locations. This will help us determine whether a particular type of request is contributing to the impact and allow us to restore service incrementally. Additionally, we're rebuilding a subset of affected servers using a previous software configuration to validate whether this prevents them from becoming unresponsive, and we'll expand this approach to additional servers if we observe positive results.
---
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.
Current status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
I mean it sort of does if you know the whole system inside and out and have the ability to reason about it, but just having the code for each component doesn't by itself solve the real problem of understanding
But maybe don't understand it because they didn't write it themselves?
2. Art imitate Life
3. Goto 1
https://youtu.be/3TNpOD6bov8
I'm not comfortable with how much I love that video.
For reasons that I cannot fathom, Microsoft wants to act as the relay to my self-hosted e-mail account, if I add the account in Outlook.
I can conjecture some reasons. Datamining would be high on the list, since MS can read your mail and thus market to you more effectively. Governments might also be happier if MS can provide them with one-stop access (like Prism) to otherwise self-hosted e-mail accounts proxied through a central server.
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.
It is normally probably more reliable; except when their server is down.
It's just funny that Outlook breaks this badly.
play stupid games win stupid prizes.
maybe its the support desk burnout talking, but if you rely on MS apps and services you're gonna have a bad time.
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.
In a corporate environment, I don't think this would be that unusual. But yes, it's hard to imagine someone would do that in a personal setup.
Great oldschool UI coupled with support for all the modern protocols, and consistently updated: https://www.rimarts.jp/downloads/B2/Readme-e.txt
I use Gmail's web interface for my Gmail account (which, I'll admit, makes my little rant above more than a little hypocritical)
And in my self hosted email setup I use RoundCube (web interface).
Na, that would simply be the kaleidoscope part you mentioned, wouldn't it? For what it's worth, I found the combination just as peculiar as you did.
Unfortunately, being someone who speaks up nowadays has been portrayed as being an asshole.
How dare you!?
I’m pretty certain because my company’s phishing-test emails skip my filters (I assume admins have a “skip filters” toggle). Which, hilariously, makes it even easier to ensure there’s a place that contains only phishing test emails (filter all not on allow-list of domains to one place, filter all on that list to another, ta-da, the main inbox now contains only phishing test emails)
I assume they do the same thing with non-MS email if you use their client, rather than maintain two filter implementations.
All around, yeah, wow, super gross.
Biggest data heist and most obvious US intelligence operation in human history. I can't fathom why AVs don't treat "Outlook New" as info stealer malware.
One of GitHub's services will be down again by next week.
Throttle the hell out of everything, then slowly ramp traffic back up.
I'm confident they've already tried this exact thing. This is cloud 101 in 2026.
> Current status: As part of our ongoing efforts to advance the recoverability of our frontend servers, we’re evaluating traffic controls that can be applied to increase capacity and stability. This includes traffic optimization actions such as traffic throttling, protocol adjustments, and failover routing intended to improve stability in active regions. In parallel, were expanding internal testing to track activity within a contained environment to improve traffic monitoring and issue detection capabilities.
That...kinda reads like they're just trying it? I'm assuming there's something being missed or it's a "fuck it try it again" but I do wonder if some story is going to come out of people in the decision making seats who don't know what they're doing.
Any other service that interacts with Outlook in some way will create downstream effects in other services expecting Outlook to work normally.
If your org is using Intune or Defender EDR then you probably also are impacted.
The Y axes are entirely independent, and so when there's an outage for Microsoft Outlook (which peaked at ~130k reports) and you get a negligable spike in pepole who get confused and report gmail (~1k reports), the graphs all look correlated and connected.
They need to show the graphs with an absolute y-axis set by the worst outage, or scale the graphs by estimated average daily users or something.
Or, rather, it's acting like it usually does.
The worst part about Outlook is the broken search. In the world of infinitely smart AI, the e-mail search in Outlook is embarrassingly stupid.
I just assumed it was Teams being Teams.
Back on Window Mobile 6.1.
Battery life usage quickly improved. :)
DDOS?
First, you have every client retrying connections, whether automated or manual retries. This generates extra load over normal.
In addition, whichever systems come online first often get a ton of traffic sent to them, which can immediately bring them back down if you don't have ways to prevent it. You will get a wave of systems coming back online, a ton of traffic hitting them, and then falling over again.
Now, I am sure Microsoft is used to this and has procedures and systems in place to mitigate the issues (I know we did).
However, sometimes if the right combination of services are failing, even the strategies you had to avoid this sort of failure can themselves fail.
However, in other cases it can be more complicated. For example, if the requesters are other internal services, they might not be behind a single gateway (although you should then have other controls you can use). Other times, it is not easy to block the RIGHT requests, because it is hard to distinguish which backend services will end up being hit by a request (a single request can trigger multiple calls to multiple services).
There is also the problem of catch up - if a system in a stable state is close to max capacity, it might never have the capacity to recover from a failure even if the entire system is restored. For example, imagine a log processing system that can just barely handle the normal peak load; if you have a failure where your producers locally store logs until they can send them upstream, you will have to clear that backlog, which requires additional capacity beyond a full steady state, which you might not have.
For Copilot.
This seems to be the smoking gnu, now what would it be ...
(I've recently been revisiting the X-Files. Can recommend.)
I'll get back into it. Can't recommend it highly enough.
I saw a frog smoking on The Little Rascals once, but never a gnu.
EDIT: Seems like now they confirmed that: "We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service."
@MSFT365Status
16m
We've not identified any recent change correlated with the start of impact; however, our investigation indicates the failed health checks may originate from a specific component that's responsible for processing server health. We've taken steps to prevent additional servers from being impacted while we work to return the affected servers to service. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as status.cloud.microsoft if the admin center is not available to you.
> Previous status: We're continuing to work through restarting and validating the affected servers to safely return them to service, and we're exploring opportunities to expedite this process. In parallel, we're assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery.
If failures started at some point in time then something must have changed just prior to that. If no changes in traffic were detected (no DDOS) then it must have been a change, be it code or config. Duuuh.
Not at all, they could have simply hit an unexpected behavior for their infra they hadn't seen, tested, or expected before. Global scale infra gets very, very complex, and tbh this is Microsoft... they're not very good at it.
More often than not, it's DNS :)
Oh... Oh I have news for you :)
Edit: Oh, there it is.
Lamest tech company imo. Why dont you lay off some more staff, Satya, maybe that will fix the problem.
Interesting: there's a huge correlation with everybody beginning to use LLMs.
And we dismiss it as being non-causal by saying it all started going downhill before the advent of LLMs?
I don't buy it. I think we're seeing the results of what happens when you hand the keys of the kingdom to LLMs.
It's been full speed downhill for many years, and the failure modes are pretty distinct.
Current industry best practice is to use LLMs improperly.
That doesn’t mean the code/result doesn’t still need to meet our engineering standards.
One of the best ways to deal with doing something the wrong way is to get rid of all the people who know how to do it correctly. That way no one knows any better, so no one has to confront the fact they're actually doing it wrong.
That is a software issue.
Service quality is in better hands after the layoffs, at least that’s what investors are led to believe.
The number of times it has spit out a python program where a much simpler bash script would do, is too many to count.
I have a pet theory that if you don't know what you really want, and aren't skilled enough to understand what you got, infra code is THE WORST.
Anecdote: I wanted a simple change to an ansible playbook today. GPT-6-Astra/codex came up with the most convoluted, brittle solution possible the first time, even though it was extending and already clear, idiomatic playbook. It took some amount of offensive and critical prompting to get it to use ansible's built in modules and tooling to do the same job - and do so with nearly 80% less configuration and like 1000% more human readability.
Some part of me harbours a sneaking suspicion that the "throw everything at it" ethos is by design, not as a defensive measure against crappy code, but as a way to ensure there's so much code and it's so convoluted orgs and operators (or developers) are stuck/addicted.
It's still a force multiplier - but it's by no means driverless, especially for existing/already-running infra.
(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.
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.
ThousandEyes Internet Insights offers a public outage map at https://www.thousandeyes.com/outages/ that is MASSIVELY more accurate (and faster to detect) than Down Detector because its based on actual telemetry and not on crowdsourcing.
They indicate sharepoint is getting blown out... again.
There will be a more detailed message when we finish the SII on our status page at the link I previously provided, but the short version is we took way more traffic than normal to our platform and the related workers were running out of memory.
No. It requires an account now, and they did away with the recent posts firehose.
I often know about outages dozens of minutes in advance of it being posted on official channels (or in the case of AWS, three days later...).
So what if the resolution is low because people can't log in to Fortnite and an Azure outage gets shown as an Epic Games outage. Doesn't matter. The live feed is incredibly reassuring from a "down for anyone else this instant, before official status page has a chance to see it?" Saves me so much time knowing whether it's a me-or-them issue.
And with Google is people complaining Chrome doesn't load their "pages". I bet they mean outlook.
That's a bold claim to make on HN.
A few more outages though.. maybe?
I can tell you somewhat anecdotally that people who usually forget about this stuff are starting to notice.
The 2011 Blackberry outage burried RIM..... companies ran away from them faster than a greyhound with its arse on fire.
One can only hope. But I am not so sure. No one seems to want to employ a local sysadmin these days.
> Current status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
And why do all the update messages sound like AI slop?
EDIT: with the most recent one it seems they might be moving backwards …
> As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
My knowledge of this isnt great, but I remember being given a briefing on some of this years 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.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
So really anything is on the table at this point
So my bet is if this is in any way AI related - perhaps the reasoning should go the other way around and is not mere dumbness of otherwise great company everyone’s buying like crazy for years now. Even my diehard Apple fans friends own MS stock.
Abscence of evidence vs evidence of absence notwithstanding, it’s probably best not to overly speculate.
Occam's razor.
> 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.
Status page is down. Much of our org is halted.
Fingers crossed that Azure isn't impacted (seems fine so far)
(https://www.geekwire.com/2026/microsoft-makes-new-voluntary-...)
Just clarifying this in general, when a company makes a voluntary offer to some segment of employees, especially at this size, it is a statistics game of how many people accept the buy out.
They did not make the offer to 25% of the employees to downsize by 25%, they did it to downsize by 5% (or something like that), and then made the offer based on how many they expect to accept. This is specifically covered in this line of the geekwire article:
> Microsoft didn’t provide a projection for how many employees will accept, but the company told GeekWire it anticipates a much smaller share than the roughly 30% who took its earlier voluntary retirement offer, which went to longtime employees more likely to take the deal.
They probably expect 10-20% of those offered to take it, which would result in a 2.5-5% total downsizing.
Or is this just a gesture of goodwill to avoid people jumping the ship on their own?
And the other part is the "goodwill" you mention - if you jettison people for nothin en masse, word gets out, and make it hard to hire in the future
People who aren't motivated and/or don't back themselves to get another job will stay (i.e. probably the people you want to get rid of)
Claims do affect the rate they pay next year, but the company isn’t “on the hook” for you personally, at least not any more than they are for your social security income.
And everybody has spent a year letting AI write code. Correlation is not causation, but I wonder...
Personally I kinda enjoy these outages…
The page is showing a "Service Degredation" for "Microsoft 365 (Business or Enterprise)"
Updates below in reverse chronological order:
From the Thurdsay, November 12, 2026 at 7:30:36 PM UTC update:
Current status: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure. We're investigating what's causing these servers to become unavailable while we work to safely return them to service.
---
From the Thurdsay, November 12, 2026 at 7:16:03 PM UTC update:
Current status: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've also moved traffic for some services off the affected infrastructure to further reduce load, with additional traffic moves in progress.
---
From the Thurdsay, November 12, 2026 at 6:59:24 PM UTC update:
Current status: We've completed redistributing connection traffic across our worldwide infrastructure, and we're moving additional traffic off the affected infrastructure to further reduce load. We're also restarting affected servers to return them to service. In parallel, we're investigating whether the elevated traffic reflects a genuine increase in requests or a shift in how traffic is being routed across our infrastructure.
---
From the Thursday, November 12, 2026 at 6:32:25 PM UTC update:
Title: Users may be unable to connect to multiple Microsoft 365 services
User impact: Users may be unable to connect to multiple Microsoft 365 services.
More info: Potentially impacted services include:
- Exchange Online
- Microsoft Teams
- SharePoint Online
- Microsoft Copilot 365
- Microsoft Defender XDR
Current status: We’re investigating an issue impacting multiple Microsoft 365 services and we've determined the affected infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're restarting and repairing impacted portions of this infrastructure to restore capacity, and reviewing an unexpected increase in a specific type of service traffic to determine whether it's contributing to the elevated load. In parallel, we're evaluating options to redirect traffic to alternate infrastructure to expedite relief.
Scope of impact: This issue may affect users attempting to access the affected Microsoft 365 services.
---
From the Thursday, November 12, 2026 at 6:10:02 PM UTC update:
Scope of impact: This issue may affect users attempting to access the affected Microsoft 365 services.
User impact: Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods.
More info: Potentially impacted connection methods may include:
- Outlook on the web
- Messaging API (MAPI)
- Exchange ActiveSync (EAS)
- Representational State Transfer (REST) API
Current status: We’ve identified connectivity errors occurring on a portion of Exchange Online infrastructure which receives and processes users’ access requests. We’ve collected networking logs to review to further investigate the source of these errors and confirm our next steps.
Scope of impact: This issue may affect users attempting to access their mailbox in Exchange Online using the affected connection methods.
Next update by: Thursday, November 12, 2026, at 8:00 PM UTC
---
Aside: What with the nature of the Teams, OneDrive, etc, products being Sharepoint and Exchange in a trenchcoat this is probably creating quite a mess for services besides Exchange Online, too.
Edit: Looks like the status page needs a status page.
Edit: Verified w/ multiple other parties that Teams and OneDrive are having issues, too. Interestingly, Microsoft 365 Family services are working fine. That makes me wonder if that product is running on separate infrastructure (or just hasn't caught fire yet).
Edit: The RSS feed seems to load fairly quickly: https://status.cloud.microsoft/api/feed/mac
What MS has posted so far:
>> Microsoft 365 Status >> @MSFT365Status >> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543. 12:54 PM · Nov 12, 2026
>> Microsoft 365 Status >> @MSFT365Status >> While we're working to mitigate impact, we've confirmed the issue may affect Microsoft 365 service connectivity for users in any region, more information will be provided in the Microsoft 365 admin center under EX1550543.
>> Microsoft 365 Status >> @MSFT365Status >> We've determined a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're providing more information under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft
>> Microsoft 365 Status >> @MSFT365Status >> 20m >> We've begun redistributing connection traffic across our broader worldwide infrastructure to help balance the load. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft if the admin center is not available to you.
[0] https://x.com/MSFT365Status/status/2120938282204688468
The biggest site I work for, who went M365 hybrid last year, has incurred more Exchange downtime today than they had all of last year with their on-prem Exchange servers.
Without anything else to go off of it points to it certainly being a capacity, traffic, routing issue.
https://www.youtube.com/watch?v=t62ZRncv2d4
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.
I mean, either roll back your update or there is a malicious actor involved.
Current status: As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
We will continue to share more information as soon as we have it, and for now we can confirm that there is no indication this is the result of malicious activity. We’ll continue to apply learnings towards remediation actions as we confirm effectiveness mitigation actions.
https://en.wikipedia.org/wiki/SQL_Slammer
https://en.wikipedia.org/wiki/Conficker
What else can you expect from Microsoft? Satya Nadella, the CEO of Microsoft is from India and as expected has outsourced so much to India.
> "Milken said earlier that if a US company replaced the US-born CEO with a CEO born in India, he buys the stock.
> The first thing they start doing is cutting US jobs and offshoring or automating them."
https://timesofindia.indiatimes.com/world/us/if-a-company-re...
"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."
- 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.
7:52 PM UTC: We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service.
7:30 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure. We're investigating what's causing these servers to become unavailable while we work to safely return them to service.
7:16 PM UTC: We're aggressively pursuing all pathways to reduce impact. As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event. We've also moved traffic for some services off the affected infrastructure to further reduce load, with additional traffic moves in progress.
6:59 PM UTC: We've completed redistributing connection traffic across our worldwide infrastructure, and we're moving additional traffic off the affected infrastructure to further reduce load. We're also restarting affected servers to return them to service. In parallel, we're investigating whether the elevated traffic reflects a genuine increase in requests or a shift in how traffic is being routed across our infrastructure.
I'd rather Microsoft host it for me than have to maintain a team of people with Microsoft Exchange skills running either on a cloud environment (similar issues) or on my own infrastructure.
I for one don't miss the days of Exchange going offline or having issues and being the person having to try figure it out.
Microsoft has much better reliability than MOST companies.
When your outsourced system to Microsoft goes down every few months your boss can’t yell at you
Outsourcing is about shifting blame elsewhere
> 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.
Deeply irresponsible.
> They shouldn't have to care either.
According to what realistic principle?
From the individual's perspective Microsoft might seem like the better choice if they can achieve higher availability, but the societal cost is so much greater when the one basket you've put all your eggs in breaks, even if everyone holding their own egg on average results in more broken eggs per year.
In other words, a day that ends in "y".
My company was recently acquired by a company that uses Office, so I'm using Microsoft products for the first time in 15 years. It's absolutely APPALLING how bad they are. I assumed they got fairly usable in the last 15 years, but it seems they've gone backwards.
For all my gripes about GSuite, ... I don't know how businesses can justify using software this bad.
O365 is Microsoft Office shoehorned into running in a web browser.
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.
Hope this entertains you while we can't get to our emails.
I think it's safe to say, if the server is unresponsive, the change is not effective.
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.
That sounds bad
surly MS can afford flagship models.
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.
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).
Yeah, I'll stick to Notepad and my local TODO.txt file...
None of the admin ran shops are down 1 day per year.
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.
After that they will tackle email servers.
>Previous status: We’ve monitored the status of the changes applied to improve serviceability and confirmed that change is not taking as expected. We’re identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances.
>Current status: As part of our investigation into the sustained traffic management imbalances, we’re reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing. This includes verifying the reasons for service failures so we can develop specific actions to improve stability.
What a dumpster fire
Because, well, once upon a time there was Exchange Server and MAPI (the "Messaging API"), and that actually worked pretty well, and pretty much everyone started using it (or one of its EWS/ActiveSync offshoots), but then the Internet happened and ruined everything, but we got MAPI-over-HTTPS eventually, which by that time had grown so many warts that nobody at Microsoft really understood it anymore, so that got deprecated, even though, well, everyone and everything still uses it.
The new hotness was Azure-slash-Office-365, and that's where the "new Outlook" web interface lived and (sort-of) continues to live, and the on-prem customers got stuck with the "Exchange Subscription Edition", which was basically Exchange 2019 plus security hotfixes at extortionate rates, but with none of the new functionality.
And, since MAPI continued to be really, really hard even in the age of Copilot, access from the new hotness to the deprecated on-prem servers was implemented via IMAP (LOL), but force-proxied via the outlook.com cloud/clownshow.
Which is why, right now, many Microsoft customers that thought they were self-hosting their email are entirely down. Lessons might be learned here, but I sort-of doubt it...
Sure, "New Outlook" on Windows is still entirely broken (including stuff like, oh, re-ordering mailboxes), but on Mac it's actually quite usable, and even allows you to switch off the IMAP proxying.
Also laughing at our ops guys who are now absolutely helpless and have people phoning them. I warned about this on our risk call and it was seen as low probability low risk. I hope it's down for a few hours :)
So in 10h
Now? I dont care Im logged off.
Anyone hoarding weights will become a dissident.
So.. > Be the last standing SRE at Micro$slop > Your mentors have all left, taking the exit payout, now your days are the best b/c you answer to nobody and can hide in your mountain of markdown. > You knew each of the 7 different products named CoPilot are used to monitor your performance. So you set them all up talking to eachother, burning tokens and API limits. > You are team top performer now, you get all the important decisions now > You walk in the office this morning, CISA is sitting at your desk, with CVE-2026-124194 on your whiteboard > 'You have a patch for this right, China is actively exploiting our Defense primes..'? > Oh no, I haven't landed a patch in prod since my mentor left (because he actually did most of the work) > Oh well, must be close enough, LGTM, CISA seems upset so better just yeet this to prod... > ...
inb4 this is more accurate than anyone wants it to be.
Gotta love the PR damagecontrol speak for global outage.
10 hours later, Outlook still down
> [Home Affairs Minister Tony Burke] says the government has activated a digital resilience agreement with Microsoft today to ensure Australia gets priority:
> "That agreement has in fact been activated today to make sure that we get appropriate prioritisation of Australian interests in this across everything.
It's a little pathetic-seeming to plead for special treatment from Microsoft. I get Australia is an important strategic alliance* for the US, but unless these resiliency agreements are rare... what meaningful prioritisation of "Australian interests" can we expect from MS?
*a useful staging ground to field subs into the South Pacific and Indian Ocean
Or maybe ai broke containment and it’s doing this for the lulz.
[1] https://github.com/customer-terms/github-online-services-sla
451 4.3.2 Temporary server error. Please try again later ATTR2 [MI3PEPF00008486.eurprd02.prod.outlook.com 2026-11-12Txxxxxxxxxxxxxx]
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)
Sure GTA6 may be a slight uptick in the amount of data being downloaded like any new game being released, but I would wager that the amount of data they are normally pushing out for downloads just on a regular basis (wether new purchases, redownloading games, game pass, etc) is already quite high.
If they roll it out evenly the week prior, then today (1/7th) is just 75 PB. To get that done in a single day would require a sustained 6.9 Tbps.
I'm sure this is all handled by a CDN at some level... but again it's not nothing.
6.9 Tbps to get it done in a single day is even 3x less than the minimum on Steam in the last 48 hours https://store.steampowered.com/stats/content/ and they don't even have GTA VI to distribute.
Maybe if people are spinning up simple VMs and VPCs they can manage multicloud through a hub, but if you're using the big three for what they're meant for, you're using cloud DBs, API gateways, lambdas, and whatnot. With how much tuning, billing monitoring and specific configuration is needed, it seems like that'd be a hard thing to abstract. Even using an abstraction like Terraform to try to keep out of the weeds takes a lot of work, from what I remember five years ago.