Microsoft 365 Outage: What Email Continuity Plans Miss

Your application loads. The database is healthy. A customer clicks the button that should move their work forward, then waits for an email that never arrives.

From your monitoring dashboard, the product is available. From the customer’s chair, it is unusable. The Microsoft 365 outage on 12–13 November 2026 exposed a gap in continuity planning for email: your application can work while the next step waits on somebody else’s inbox.

For current Outlook and Microsoft 365 service status, use Microsoft’s status page.

The useful response is to trace a piece of work all the way to completion. Your independence from a provider depends on whether people can receive the message, enter the application, make the decision and reach you when something fails. Owning the server covers only part of that journey.

An Outlook outage can block your support intake

On Friday morning, CloudTree told customers it was not receiving support-ticket emails. For unrelated technical problems, it directed them to call support so its phone agent could raise a ticket. At 14:03, CloudTree reported that its Microsoft accounts had reconnected and said it expected email ticket intake to work again, with monitoring continuing.

That operational detail exposes a larger problem. The failure removed a way to tell the supplier about another failure. A customer could have a separate hosting problem while the route normally used to report it was unavailable.

Apply that situation to your own business. A working support queue helps only after the request reaches it. A form that forwards to the same failed mailbox may look like a second channel while ending at the same blocked destination.

The fallback has to complete the handoff. Someone answers the call, records the problem somewhere the team can access and gives the customer a way to follow up. Publishing a phone number is the start of that process. Establishing who can use it and what happens next makes it useful.

This is why an outage notice needs to describe the affected action. “Our servers are operational” leaves a customer guessing whether to keep waiting, retry or contact somebody. “Support email is delayed; use this route for urgent problems” gives them a decision they can make.

A second email provider cannot open the recipient’s inbox

You can move your own email and still need to communicate with a customer who uses Microsoft 365. Their receiving infrastructure remains part of the exchange.

Bright Software Group’s incident notice illustrated this boundary: its applications and separate email-sending service were functioning, while delivery to recipients using Microsoft services was affected. Its own systems working did not remove the receiving side’s dependency.

For a startup, that distinction changes what an email metric means. A job completing in your application proves that your code reached that stage. A sending service accepting a message proves another stage. Neither observation tells you that the recipient can open their mailbox and act.

Consider an illustrative hiring workflow. You prepare an interview invitation, your sending provider accepts it and the candidate’s mailbox is unavailable. The interview still needs a response. Switching your outbound provider cannot repair access to the candidate’s inbox.

You cannot control every recipient’s infrastructure. You can decide what your product assumes after sending. Does the screen claim that the person has been notified? Does a deadline start immediately? Can the person find the invitation in an authenticated account, or does the email contain the only usable route?

Those are product decisions. They deserve the same attention as retries and mail-server configuration, because they determine whether a delayed message becomes a missed obligation.

Login, scheduling and support share more than a logo

The University of Bath’s outage updates exposed another kind of coupling. Its early investigation said basic Teams functionality appeared to work and authentication appeared unaffected, while Outlook was inaccessible to staff. The university also identified effects on TOPdesk and its Applicant CRM because they relied on Outlook for email; its notice warned that scheduling, invitations and calendar actions could fail.

What matters is how unevenly the failure spread. Some functions remained usable while related work was interrupted. A broad label such as “Teams down” or “Microsoft working” would have concealed the distinction people needed to plan their day.

Trace your own dependencies beyond the vendor name, too. An existing session, a fresh login, a password reset and an account invitation are different journeys. One may work while another waits on email.

A second collaboration application may be accessible to staff already signed in, yet require an email code for someone opening it on a new device. A status page may be publicly readable, yet its publisher may need the affected identity service to post an update. A backup channel that relies on the failed channel for entry has a narrower use than its label suggests.

Check these paths with the people who would actually use them. A founder’s open browser cannot establish that a new customer or an authorized support colleague can get in. Record the specific action that fails, rather than marking the whole application available or unavailable.

Build an email continuity plan around the work

An email continuity plan starts with the work that cannot wait: an interview happening today, an urgent support request or an approval with a real deadline. Buying a second tool for every function gives a small team more systems to maintain; it only helps if people can complete those tasks.

For each one, write a short account of how it completes. Include the person receiving the message and the access they need. The following examples are planning prompts, not reports of failures during this incident:

Microsoft’s own incident-mitigation guidance recommends parallel email, phone and SMS routes when incident response depends on Exchange. Apply the same test to your customer workflows: can the alternative reach the right person without the unavailable inbox?

A fallback can be a deliberate pause. If you cannot safely authenticate someone without their mailbox, explain the delay and preserve their place in the process. An outage is a poor reason to improvise identity checks or grant access through an unverified message.

Our founder continuity rehearsal examines whether an authorized colleague can work without the founder. The question here is different: can that colleague complete the task when a communication dependency is missing? Authority and reachable infrastructure both matter.

Recovery ends when the work catches up

In a statement carried by the BBC at 16:51 GMT on 13 November, Microsoft attributed the incident to an issue introduced during an earlier network capacity upgrade that surfaced after a recent network change. It said the issue was unrelated to cyber activity or AI/agents, that the underlying problem had been addressed and that restoration continued. A full post-incident report was still pending.

Any explanation of the cause needs to stay within that account. It also leaves your team with a separate recovery question: what happened to the work waiting on those messages?

When access returns, inspect the outstanding obligations before assuming the day has caught up. In your own workflow, look for unanswered requests, expired links and appointments changed through another channel. Reconcile any temporary record with the usual system so colleagues do not act on conflicting versions.

Then change one concrete assumption you discovered. Give an invitation an accessible home beyond the email. Make the support fallback reach an independent intake route. Explain that a message is awaiting delivery instead of implying that the recipient has acted.

The dashboard can tell you when your application is healthy. To know whether your business is working, follow the customer past the send button.