For close to a day in mid-November 2026, a large share of office work simply stopped. People could not open Outlook. Team meetings failed. SharePoint files would not load. Copilot and other Microsoft 365 tools that depend on the same backbone went quiet too.
The trouble started shortly before 1:00 p.m. Eastern Time on Thursday, 12 November 2026, which is 11:30 p.m. on 12 November in India Standard Time (Asia/Calcutta). It ran through the Friday morning workday in the United States, and through the business day in Asia and Europe. Microsoft later said the disruption lasted nearly 24 hours for many customers. By Friday it apologised, said the underlying problem had been fixed, and was still bringing some customers back online.
This was not a story about one broken app. Email, calendars, chat, files and even some AI tools now sit on the same few cloud platforms. When one of those platforms has a bad day, hospitals, airlines, shops and software teams feel it together. If you run a business on Microsoft 365, or you build products that send mail or book meetings through it, this outage is worth studying while the details are still fresh.
Key takeaways
- The outage began shortly before 1:00 p.m. Eastern Time on 12 November 2026 (11:30 p.m. IST that day) and ran for almost a day, hitting Outlook, Teams, SharePoint, Copilot and other Microsoft 365 services across the United States, Europe and Asia-Pacific.
- Microsoft said it found no sign of a cyber attack. It later said the disruption came from an issue during an earlier network capacity upgrade.
- Microsoft extended its email retry window to 48 hours so delayed messages had a better chance of arriving. Do not resend mail that is still queued. Resend only messages that bounced, and issue a fresh code for one-time passwords and reset links.
- A mailbox that opens again does not prove that every delayed message has arrived. Check mail queues, message traces and any app that sends mail through Microsoft.
- This is a planning problem, not only an IT problem. You need a way to reach customers and staff when Outlook and Teams are down.
What went down
Microsoft 365 is the bundle of work tools many companies use every day. Outlook is the email and calendar app. Teams is the chat and meeting app. SharePoint holds shared files. Copilot is Microsoft's AI assistant, and it needs the same mail and file systems to do its job. When the shared infrastructure behind these tools failed, all of them suffered.
People in the United States still had trouble on Friday morning. Colleagues in Asia and Europe lost a full working day. Other products that connect to Microsoft — booking tools, support desks, invoice mailers and custom apps — failed as well, because they were waiting on the same services.
Some organisations spoke about the impact in public. The United Kingdom's National Health Service said some of its services were affected, but patients should still attend appointments. A hospital group in south-west London warned that phone calls might take longer. Air India said it had temporarily rerouted emails so customer messages could still arrive, and that its flights were not affected. At least two companies delayed a public earnings update because their own systems depended on Microsoft 365.
A cloud outage does not only annoy office workers. It can delay medical admin, customer support and financial reporting. The organisations above are not our clients. They are examples of how wide the impact became.
What Microsoft said caused it
Microsoft was clear on one point: it did not see malicious activity. In plain words, this does not look like a hack. The response to a cyber attack is very different from the response to a platform fault.
The first updates on Thursday described a traffic surge and a large number of servers that became “unexpectedly unavailable.” The remaining servers then had to carry more load than they could handle. Some also failed their automatic health checks. A health check is a simple test that asks whether a server is still working. If that test misfires, good servers can be pulled out of service, and the remaining ones get even busier.
At 4:00 p.m. Eastern Time on Thursday (2:30 a.m. IST on Friday, 13 November 2026), Microsoft said it had tested a different way to check server health, and that this change brought some of the affected servers back. It then applied the change more widely and prepared automatic systems to detect and restart servers that had stopped responding.
By Friday, Microsoft’s account had settled on a clearer cause: an issue during an earlier network capacity upgrade. In simple terms, a change meant to give the network more room appears to have gone wrong. Microsoft said the underlying cause had been addressed, but some customers were still waiting for a full recovery. It also said it would publish a full incident report after its review. As of 13 November 2026, that report was still pending.
Some posts claimed that Amazon Web Services or Google Cloud failed at the same time. Amazon said its services were operating normally, and that unrelated disruption was leading to inaccurate reports. Check the provider’s own status page before you assume a second cloud is down.
A simple timeline
| When (IST, Asia/Calcutta) | What happened |
|---|---|
| 12 November 2026, 11:30 p.m. IST | Connectivity problems began, shortly before 1:00 p.m. Eastern Time. |
| 13 November 2026, 2:30 a.m. IST | Microsoft said a new health-check method had brought some servers back, and that it was rolling the change out more widely. |
| 13 November 2026, Friday morning in the US, afternoon and evening in India | Outlook and other tools started to return for more users. Microsoft said email queues were approaching normal levels, but intermittent issues were still expected. |
| 13 November 2026, about 9:00 p.m. IST (10:30 a.m. Eastern Time) | Microsoft reported encouraging recovery progress and improving email delivery, while still restoring service for some customers. |
Times above are converted from Eastern Time (UTC−5 in mid-November 2026) into India Standard Time (UTC+5:30). Microsoft said it was taking affected systems offline, fixing them, and bringing them back in stages, so that turning everything on at once would not create a second traffic spike.
What happened to email
Email was one of the most painful parts of this outage. Many messages were not rejected. They were delayed. That difference matters.
When a mail server rejects a message, it sends a permanent “no” and the sending system usually gives up. When a mail server defers a message, it sends a temporary “try again later.” The sending system keeps the message in a queue and retries. Microsoft said it was working to protect delayed messages and reduce the backlog. It extended its email timeout window to 48 hours. That window gives messages stuck inside Microsoft’s own systems more time to get through instead of bouncing.
This is the practical advice for anyone who sent or expected mail during the outage:
- Do not resend a message that has not bounced. If your mail tool shows the message as queued, deferred or delayed, it is probably still sitting in a retry queue. Sending it again can create a duplicate once the original gets through.
- Resend only mail that expired and bounced, and only after Microsoft is accepting mail again. Start with invoices, contracts and replies that people are waiting for.
- Do not “resend” a one-time password or a password-reset link. Those links expire. If a customer never received the code, issue a fresh one.
- Check your suppression list. Some email platforms stop writing to an address after a bounce. If an address was added only because a message timed out during this outage, take it off the list.
- Do not rush to change SPF, DKIM or DMARC records. Microsoft’s updates described lost server capacity and a network problem, not a fault in your domain’s email authentication. A hasty DNS change will not deliver a delayed message, and it can break mail that was working.
If you run Microsoft 365 for your company, open the admin centre when service is back and check more than the inbox. Look at message trace for mail that is still pending. Recheck quarantine items you tried to release during the outage. If you have a hybrid setup, with some mailboxes in the office and some in the cloud, test mail in both directions. Microsoft warned that on-premises mail flow could be affected when it went to or from Exchange Online.
Custom apps need a check too. Many Laravel and Node.js products send or read mail through Microsoft Graph, which is the programming interface for Outlook, calendars and contacts. If your app saw timeouts on 12 or 13 November, look at its error logs. A Graph request that failed may have left nothing in a mail queue, so it will not retry on its own.
Why a single outage stopped so much work
Twenty years ago, email, file shares and phone calls often lived on different systems. If one failed, the others still worked. Today, a mid-size company may use Outlook for mail, Teams for meetings, SharePoint for files, and Copilot for writing and search — all under one login. That is convenient. It is also a single point of failure.
Think of a small firm in Ahmedabad, or a client team in Dubai or Toronto. Sales lives in email. Delivery updates go out from a web app that uses Microsoft to send messages. The daily standup is a Teams call. The contract is a SharePoint file. When Microsoft 365 is down, that firm does not have a backup office. It has a quiet office.
None of this means you should abandon Microsoft 365. It means you should ask a hard question: if this happens again tomorrow, how will we take a customer call, send an urgent invoice, and tell staff what to do?
A practical checklist for the next outage
Use this list as a tabletop exercise with your team. Walk through it once now, while the memory of this incident is fresh.
1. Write a short “Microsoft is down” plan
Keep it to one page. Name the person who declares the incident. Name the backup channel you will use to reach staff — a phone tree, a WhatsApp or SMS group, or a second chat tool that does not run on Microsoft 365. Write the customer message you will post on your website or social accounts. Decide who is allowed to say “we are down” in public, so people do not invent updates. If you are in India, the Middle East, Canada or the United States, remember that a US-daytime failure can start late in your evening. This outage began at 11:30 p.m. IST. Your plan should say who is reachable after that hour, not only during office hours.
2. Keep a way to send urgent email that does not depend on Outlook
This can be a second mailbox at another provider, used only for emergencies, or a transactional mail service that your website already uses for password resets and invoices. Test it twice a year. An unused backup that nobody can log into is not a backup.
3. Store the files you would need offline
You do not need a copy of every document. You need the few things that keep the business moving: a customer contact list, a current price list, an incident call sheet, and any work-in-progress that cannot wait a day. Keep them in a place that still works if SharePoint is offline, and limit who can open them.
4. Make meetings fail more gently
If a client meeting is booked in Teams, put a backup video link in the invite, or agree to switch to a phone call after 10 minutes. Write that rule down so people do not sit on a spinning login screen.
5. Teach staff what to do with delayed mail
The worst extra damage after an outage is a flood of duplicate emails and expired login codes. Share the five email rules above with anyone who sends invoices, OTPs or support replies.
6. Check the apps you built on top of Microsoft 365
If your product books appointments, creates users, or files support tickets through Microsoft, add clear error messages and retries. Do not show a generic “something went wrong” when the real problem is that the calendar API is down. Log the failure, queue the work if you can, and tell the user to try again later. For Graph-based mail, assume a failed request may need a manual retry after service returns.
7. Rehearse once, not only on paper
Pick a quiet afternoon and pretend Outlook and Teams are down for two hours. See whether people can still reach a manager, find a customer number, and send one urgent message. Those gaps are cheaper to fix now than during a real incident.
How we think about this at DayDecoder
DayDecoder is a custom software company in Ahmedabad. We build web applications, AI features and cloud setups for clients in India and abroad, often with Laravel, Node.js and integrations into tools such as email and calendars. When we connect a product to Microsoft 365, we treat that connection as something that can fail. We plan for retries, clear errors and a way to keep serving users if a single vendor is having a bad day.
No setup is immune to a platform outage. If you want help reviewing how your app depends on Microsoft 365, or you want a simple incident plan for your product, use the contact form. We reply within one business day.
FAQ
Was this a cyber attack?
Microsoft said it found no sign of malicious activity. Its later explanation pointed to a problem during an earlier network capacity upgrade, not a hack.
When did the outage start and how long did it last?
Problems began shortly before 1:00 p.m. Eastern Time on Thursday, 12 November 2026, which is 11:30 p.m. IST that day. Microsoft was still restoring service about a day later, and described the disruption as lasting nearly 24 hours for many customers.
I sent an email during the outage. Should I send it again?
Not if it has not bounced. Many messages were delayed, not rejected. Microsoft extended its retry window to 48 hours. Resend only mail that came back as a bounce, and issue a new code for one-time passwords.
My Outlook is working again. Is everything fixed?
Not always. Access and delivery recover at different speeds. Check whether queued mail has arrived, review quarantine, and look at any custom app that sends mail or reads calendars through Microsoft.
Were Amazon Web Services and Google Cloud down too?
Some public posts said so. Amazon said its services were operating normally and pointed people to its own status dashboard. Check the provider’s status page before you act on a rumour.
Written by
Prakash Tank
Founder & Full-Stack Architect, DayDecoder
Prakash started as a certified Laravel developer and grew into a full-stack architect who owns a project end to end: requirements, architecture, development, deployment, and support. He designs event-driven systems with...
More about Prakash