Azure Went Down for Five Hours. Did Your Business Have To?

On July 23, 2026, Azure’s West US region went down and stayed down for roughly five hours. Outlook, Teams, SharePoint, OneDrive, and Copilot all stopped working. Businesses that run on Microsoft 365 lost email, internal messaging, file access, and AI tooling simultaneously, during a Wednesday afternoon when deals were closing, deadlines were landing, and customers were waiting for responses.

This was not a minor blip. This was the sixth major M365 disruption this year, and the longest since the nine-hour January incident. If your team spent those five hours staring at loading screens and refreshing their inbox, this post lays out what should have happened instead, what your IT provider should have been doing in the first 30 minutes, and how to build a one-page runbook so the next outage is an inconvenience instead of a crisis.

We covered the broader pattern of 2026 outages and a preparation checklist in our earlier post on Microsoft 365 outages and business continuity. This post goes deeper on the operational response: what actually happens minute by minute when Microsoft goes dark, and what separates a business that keeps moving from one that stops.

What Went Wrong on July 23

Azure’s West US region experienced a cascading failure in its identity and authentication infrastructure starting at approximately 11:40 AM Central Time. The failure disrupted token issuance for Microsoft 365 services, which meant that even users outside the West US region saw degraded performance as authentication requests backed up across Microsoft’s global network.

By noon, Outlook Web Access and the Outlook desktop client were returning connection errors. Teams calls dropped. SharePoint and OneDrive returned “Service Unavailable” errors. Copilot, which depends on Azure’s backend infrastructure for every prompt, stopped responding entirely. Microsoft acknowledged the issue on the Service Health Dashboard at 12:15 PM CT and began rolling mitigations, but full service restoration did not occur until approximately 4:45 PM CT.

Five hours is a full half of a business day. For companies in Central and Mountain time zones, the outage covered the most productive hours of the afternoon. Customer emails went undelivered. Contracts sat unsigned in SharePoint. Internal coordination fell apart because the tool everyone uses to coordinate was the tool that was broken.

The First 30 Minutes Determine Everything

The difference between a five-hour productivity loss and a five-hour inconvenience comes down to what happens in the first 30 minutes after services go down. Most businesses waste that window trying to figure out whether the problem is on their end, restarting routers, rebooting laptops, and calling their ISP before anyone checks the Microsoft 365 Service Health Dashboard.

Here is what should happen instead, broken into three blocks.

Minutes 0 to 10: Confirm and escalate. Your IT team or managed IT provider should be monitoring M365 service health automatically. When service alerts fire, the first job is confirming that the problem is Microsoft’s, not yours. Check the Service Health Dashboard, the @MSFT365Status account on X, and a third-party site like Downdetector. If your internal network, VPN, and non-Microsoft applications are working normally, the problem is upstream. Your MSP should be sending you a notification within 10 minutes confirming the outage and setting expectations: this is Microsoft’s issue, here is what we know, here is what we are doing.

Minutes 10 to 20: Activate your backup communication channel. If Outlook and Teams are both down, your team has no way to coordinate unless you established an alternative before today. SMS group threads, a Slack workspace, a WhatsApp group for leadership, or even a conference bridge phone number all work. The channel does not need to replicate Teams. It needs to carry three messages: “We know about the outage,” “Here is what we are doing,” and “Here is when the next update comes.” If your business does not have a backup channel yet, that is the first thing to fix after reading this post.

Minutes 20 to 30: Shift work to what still runs. Not everything stops when Microsoft goes down. Your ERP, your accounting software, your CRM (if it is not Dynamics 365), your phone system, and your local network all still work. Identify which teams can continue working on non-Microsoft tools and which teams are fully blocked. Sales can make phone calls. Accounting can process in their ERP. Customer service can field calls and log issues on paper or in a local spreadsheet. The people who are fully blocked should get clear direction: you are not expected to sit and wait. Here is what you can do instead.

What Your MSP Should Be Doing (and What They Cannot Fix)

A good managed IT provider earns their contract during outages. But there is an important distinction between what your MSP can control and what sits entirely in Microsoft’s hands.

What your MSP should be doing: Monitoring the outage in real time and providing you with updates as Microsoft publishes them. Confirming that your environment is not experiencing a separate, local issue layered on top of the Microsoft outage. Activating your documented outage runbook. Helping your team pivot to backup communication channels. Preparing to validate service restoration once Microsoft reports that services are recovering, because partial restorations are common and premature all-clears create more confusion than the outage itself.

What your MSP cannot do: Fix Microsoft’s infrastructure. Restore authentication tokens on Azure’s backend. Accelerate Microsoft’s engineering response. If your IT provider is telling you they can “architect around” a platform-level Azure authentication failure, ask them exactly what that means, because no amount of local configuration changes will issue valid OAuth tokens when Microsoft’s identity service is down.

The value of a strong MSP during a cloud outage is not in fixing the unfixable. It is in making sure your business keeps operating around the gap. That means having plans, communication channels, and runbooks ready before the outage hits, and executing them calmly when it does.

If your current provider’s response to the July 23 outage was silence until you called them asking what was going on, that tells you something about what you are paying for.

The One-Page Outage Runbook

Every SMB that runs Microsoft 365 should have this document printed, stored outside of SharePoint, and reviewed quarterly. It fits on a single page.

Section 1: Confirm the outage

• Check status.office.com for active incidents
• Check @MSFT365Status on X
• Check Downdetector for community reports
• Verify internal network, VPN, and non-Microsoft apps are working normally
• If all internal systems work but M365 does not, the problem is Microsoft’s

Section 2: Notify and escalate

• IT lead (or MSP) confirms the outage and sends initial notification within 10 minutes
• Notification goes to: CEO/COO, department heads, office manager
• Use the backup communication channel (define yours here: SMS group, Slack, phone bridge)
• Include: what is down, what still works, when the next update will come

Section 3: Keep working

• Teams that can work without M365: continue on non-Microsoft tools
• Teams that are fully blocked: shift to phone-based work, local documents, or take the time for tasks that do not require email or cloud files
• Customer-facing teams: switch to phone communication, use the pre-drafted customer delay notice
• Do not attempt workarounds that create security risk (personal email accounts, unsanctioned file-sharing tools)

Section 4: Service restoration

• Wait for Microsoft to confirm full restoration, not partial
• IT lead or MSP validates that Outlook, Teams, and SharePoint are all functional
• Send all-clear notification through the backup channel
• Monitor for 30 minutes after restoration for lingering issues (sync conflicts, delayed email delivery, calendar duplication)

Section 5: After-action (within 48 hours)

• Document the timeline: when the outage started, when you were notified, when you activated the runbook, when services restored
• Identify what worked and what did not
• Update the runbook based on what you learned
• If backup and recovery gaps were exposed, address them before the next incident

Store this runbook in three places: printed in the office, as a PDF on a local file server or NAS, and in your MSP’s documentation portal. A runbook that only exists in SharePoint is useless during a SharePoint outage.

Stop Treating Outages as Surprises

Six major Microsoft 365 disruptions in seven months is a pattern, not a streak of bad luck. Microsoft’s own SLA allows for roughly 8.7 hours of downtime per year on a 99.9% guarantee. The 2026 total has already exceeded that by a wide margin, and we are not through August yet.

The businesses that handled July 23 without losing revenue or customer trust are the ones that accepted this reality months ago: Microsoft 365 will go down again, the only question is whether your business goes down with it.

If you read our earlier M365 continuity checklist and have not acted on it yet, the July 23 outage is your signal. Deploy third-party M365 backup. Establish your backup communication channel. Print your runbook. Test it quarterly. These are not expensive or complicated steps. They are decisions that protect your revenue when someone else’s infrastructure fails.

For Dallas-Fort Worth businesses and companies across our service areas, our team has been through every one of this year’s M365 outages alongside our clients. The difference is that our clients had runbooks, backup channels, and a team on the phone within 10 minutes of each incident. If your experience on July 23 was five hours of confusion, that gap is fixable.