> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.
The page is showing a "Service Degredation" for "Microsoft 365 (Business or Enterprise)"
The detail says:
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.
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.
YEah, that is not loading, along with the root status.cloud.microsoft , which MS links in their Xitter update [0]
What MS has posted so far:
>> Microsoft 365 Status
>> @MSFT365Status
>> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.
12:54 PM · Nov 12, 2026
>> Microsoft 365 Status
>> @MSFT365Status
>> While we're working to mitigate impact, we've confirmed the issue may affect Microsoft 365 service connectivity for users in any region, more information will be provided in the Microsoft 365 admin center under EX1550543.
>> Microsoft 365 Status
>> @MSFT365Status
>> We've determined a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're providing more information under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft
>> Microsoft 365 Status
>> @MSFT365Status
>> 20m
>> We've begun redistributing connection traffic across our broader worldwide infrastructure to help balance the load. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft
if the admin center is not available to you.
Everyone that is a whole stack programmer (say, kernel to webapp) has seen just how unnecessarily complicated everything has become. Watching it burn to the ground would be a pornographic miracle.
My housemate texted me saying our internet is so slow because outlook wasn't loading. So I think lots of people associate email not working with entire internet not working..
With how many people are unable to associate a "broken" monitor with an unplugged HDMI/DisplayPort or power cable, it doesn't surprise me that most people would not make a disctinction between the "internet" and "Outlook".
This happens every time there's an outage. People see their email not working and go there and mark everything as down regardless of whether it is affected or not. There's nothing wrong with Gmail or AWS or Cloudflare or Facebook.
> Isn't this the company that is trying to get rid of 25% of their employees?
Just clarifying this in general, when a company makes a voluntary offer to some segment of employees, especially at this size, it is a statistics game of how many people accept the buy out.
They did not make the offer to 25% of the employees to downsize by 25%, they did it to downsize by 5% (or something like that), and then made the offer based on how many they expect to accept. This is specifically covered in this line of the geekwire article:
> Microsoft didn’t provide a projection for how many employees will accept, but the company told GeekWire it anticipates a much smaller share than the roughly 30% who took its earlier voluntary retirement offer, which went to longtime employees more likely to take the deal.
They probably expect 10-20% of those offered to take it, which would result in a 2.5-5% total downsizing.
A layoff of any real size has negative impacts to their unemployment insurance premiums and restricts their ability to file PERM for employees. Meeting those targets with voluntary separation prevents those impacts.
That’s not entirely accurate. Washington State pays unemployment, not the company. The state funds unemployment by taxing payrolls, but it’s much more indirect than most people think.
Claims do affect the rate they pay next year, but the company isn’t “on the hook” for you personally, at least not any more than they are for your social security income.
I think both parties probably benefit; people who are more likely to take the offer are those who have another reason to leave (unfulfilled, etc). This will benefit the company in the long run because they can eventually replace them with someone who want to join (people applying for the job).
Can go the other way though: people who've been there for a while, are motivated and back themselves to get another job will take redundancy (i.e. the people you want to keep).
People who aren't motivated and/or don't back themselves to get another job will stay (i.e. probably the people you want to get rid of)
You can at will fire but that doesnt stop lawsuits. Most of these require signing docs to get the payout. It is a way to cut cleanly and derisk the cut
The fact that it is always Big Even Number shows how stupid it is. Imagine if it was serious like "23.5176%" then you'd know they actually did their homework on leaning up operations instead of just cutting off limbs and seeing if it can still walk or not.
> Current status: We’re investigating an issue impacting multiple Microsoft 365 services and we've determined the affected infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're restarting and repairing impacted portions of this infrastructure to restore capacity, and reviewing an unexpected increase in a specific type of service traffic to determine whether it's contributing to the elevated load. In parallel, we're evaluating options to redirect traffic to alternate infrastructure to expedite relief.
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.
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 should have happened just prior. If no changes in traffic were detected (no DDOS) it's a change, be it code or config. Duuuh.
> then something must have changed just prior to that
Not at all, they could have simply hit an unexpected behavior for their infra they hadn't seen, tested, or expected before. Global scale infra gets very, very complex, and tbh this is Microsoft... they're not very good at it.
Unexpected behavior doesn't happen out of the blue, it's not LLM, these are deterministic systems. It's usually config change or code change, not necessarily in the component that's misbehaving, but it is somewhere.
As someone who worked in infrastructure for a large global CDN, this sort of overload issues happen all the time when trying to bring infrastructure back online after an issue.
First, you have every client retrying connections, whether automated or manual retries. This generates extra load over normal.
In addition, whichever systems come online first often get a ton of traffic sent to them, which can immediately bring them back down if you don't have ways to prevent it. You will get a wave of systems coming back online, a ton of traffic hitting them, and then falling over again.
Now, I am sure Microsoft is used to this and has procedures and systems in place to mitigate the issues (I know we did).
However, sometimes if the right combination of services are failing, even the strategies you had to avoid this sort of failure can themselves fail.
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.
With engineering rigor. They are fantastic tools for quickly navigating large codebases, ingesting large amounts of data, refactoring legacy code, compiling multiple formats of data, following defined patterns, and many other proper uses for the tools.
That doesn’t mean the code/result doesn’t still need to meet our engineering standards.
> Hopefully the people who feel that way are already close to retirement, so the choice won't have to be made for them.
One of the best ways to deal with doing something the wrong way is to get rid of all the people who know how to do it correctly. That way no one knows any better, so no one has to confront the fact they're actually doing it wrong.
I really don't see the correlation, actually. On the contrary, I'm finding nasty defects with it that have been dormant for long and handwaved away, with repros to reveal them.
It's been full speed downhill for many years, and the failure modes are pretty distinct.
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 protecting JH's departure from Nvidia, on a larger and more technical scale.
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.
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.)
223 comments
[ 3.5 ms ] story [ 80.9 ms ] thread> We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.
The page is showing a "Service Degredation" for "Microsoft 365 (Business or Enterprise)"
The detail says:
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.
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
And with Google is people complaining Chrome doesn't load their "pages". I bet they mean outlook.
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
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.
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)
DDOS?
For Copilot.
This seems to be the smoking gnu, now what would it be ...
I saw a frog smoking on The Little Rascals once, but never a gnu.
(I've recently been revisiting the X-Files. Can recommend.)
I'll get back into it. Can't recommend it highly enough.
@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 should have happened just prior. If no changes in traffic were detected (no DDOS) it's 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 :)
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.
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.
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.
It's been full speed downhill for many years, and the failure modes are pretty distinct.
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 protecting JH's departure from Nvidia, on a larger and more technical scale.
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.
[1] https://github.com/customer-terms/github-online-services-sla