Azure West US Outage — 23 July 2026: A Maintenance Bug Severed IP Routes for Five Hours, Taking Down AKS, PostgreSQL, ExpressRoute and Teams for UK Businesses

On 23 July 2026, a single bug inside Microsoft’s Azure West US region did something no marketing slide about “the cloud” ever prepares a business for: it quietly removed IP routes from more network devices than intended during a routine maintenance job, and for the next four hours and fifty-seven minutes, traffic trying to enter or leave that region simply had nowhere to go. Between 14:44 and 19:41 UTC, more than 23 Azure service families — Azure Kubernetes Service, Azure Database for PostgreSQL, Databricks, ExpressRoute, VPN Gateway, Microsoft Sentinel, Azure Virtual Desktop and Power BI among them — degraded or failed outright. And because so much of Microsoft’s own platform rides the same plumbing, the failure cascaded into Microsoft 365: thousands of users worldwide reported Outlook, Teams, SharePoint, OneDrive and Copilot falling over at the same time.

For a UK small or medium-sized business reading this on 25 July, the temptation is to file it under “American problem, far away, not my region.” That instinct is exactly the mistake. The geography of West US matters far less than the shape of what happened: a well-run, hyperscale provider was taken down for the best part of an afternoon by a routine change gone wrong, and the blast radius reached ordinary businesses on the other side of the planet through the Microsoft 365 services they use every day. Any UK organisation that relies on a single Azure region, a single connectivity path into the cloud, or an Azure tenancy nobody actively monitors is one maintenance bug away from living through the same afternoon. This article explains what actually happened, why a geographically distant incident still reached UK desks, what genuinely resilient Azure architecture looks like, and why having a managed Azure partner changes the incident-response picture entirely.

What actually happened in West US

The root cause, on Microsoft’s own account of the incident, was mundane in origin and severe in consequence. Engineers were carrying out routine device maintenance in the West US region — the kind of planned, low-risk work that happens across a hyperscale estate every day. A bug in the platform’s request conversion system, however, incorrectly marked additional devices as part of the maintenance event. Because those devices were now treated as “in maintenance,” their IP routes were withdrawn. The result was that routing was pulled from far more network devices than the change was ever meant to touch, and the region lost the ability to reliably carry traffic across its boundary.

The critical detail for understanding the impact is where the damage landed. The outage affected traffic entering or exiting the West US region — the ingress and egress paths — while traffic staying entirely inside the region was largely unaffected. That is why the experience for users was intermittent connectivity failures rather than a clean, total blackout: whether a given request worked depended on whether its path crossed the broken boundary. Requests that needed to reach a service instance in West US from outside, or leave West US to reach somewhere else, hit the missing routes. This is also why the symptom set was so scattered — a login here, a database query there, a dashboard that half-loaded — rather than a single obvious “everything is down” signal.

The list of affected services reads like an inventory of modern cloud operations. Application Gateway, Application Insights, Azure AD B2C, Azure AI Search, Azure AI Speech, Azure API Management, Azure Bastion, Azure Bot Service, Azure Data Explorer, Azure Database for PostgreSQL, Azure Databricks, Azure Firewall, Azure Kubernetes Service (AKS), Azure Monitoring Essentials, Azure Virtual Desktop, Azure VMware Solution, ExpressRoute Circuits, ExpressRoute Gateways, Log Analytics, Microsoft Sentinel, Partner Center, Power BI Embedded, Virtual WAN and VPN Gateway were all reported as impacted. Read that list slowly and a chilling pattern emerges: several of those services are the very tools a business would reach for during an incident. Microsoft Sentinel and Log Analytics are how you investigate. Azure Bastion and VPN Gateway are how you connect in to fix things. ExpressRoute is the private line your remediation traffic runs over. When the incident takes out your visibility and your access at the same moment it takes out your workloads, the reactive scramble becomes very hard indeed.

The timeline: five hours, minute by phase

The incident was resolved in a single working afternoon, but the sequence matters because it shows how a small, internal change becomes a global user-facing event and then unwinds. Times are in UTC; for UK readers on British Summer Time, add one hour — so the incident ran from roughly 15:44 to 20:41 in London.

Why a West US fault reached UK desks

The most common misreading of this incident is that it was a distant American outage with no bearing on a business in Birmingham or Bristol. The Microsoft 365 cascade is the reason that reading is wrong. Microsoft 365 is not a set of isolated national installations; it is a globally distributed platform whose services depend on shared Azure infrastructure, identity systems and traffic-routing layers that span regions. When a major region’s ingress and egress fail, the effects do not politely stop at a national border — they surface wherever a request happens to depend on the affected path. That is precisely why users “globally,” not just in the United States, reported Outlook, Teams, SharePoint, OneDrive and Copilot problems during the window.

The chart below is an illustrative ranking of how exposed different everyday business activities were to this specific style of failure — a regional ingress/egress outage that cascades into Microsoft 365. It weighs how directly each activity depends on cross-region cloud paths and shared Microsoft services. The figures are a representative model to make the shape clear, not measurements of this incident; the point is which parts of a normal working day are most fragile when the cloud’s connective tissue fails.

The shape is the lesson. The activities at the top — the ones a knowledge worker spends most of the day inside — are almost entirely dependent on Microsoft’s cloud being reachable, which is exactly why an afternoon like 23 July feels like the business stopping rather than a technical footnote. The single low bar at the bottom is the tell: the only work that carried on untouched was work with no cloud dependency at all, which for most modern UK SMEs is a vanishingly small slice of the day. Cloud concentration is not a bad thing — the productivity, security and cost benefits are real — but concentration without resilience is how a distant bug becomes your problem.

The downtime budget nobody talks about

Cloud marketing leans heavily on uptime percentages — “three nines,” “four nines” — and they sound reassuring until you convert them into minutes. A service promising 99.9% availability is allowed to be down for roughly 8 hours and 45 minutes across an entire year and still hit its target. A single incident of the length seen on 23 July does not just dent that allowance; it consumes most of it in one afternoon. The donut below shows how much of a full year’s 99.9% downtime budget a 4h 57m outage burns through at a stroke.

The number reframes the conversation. Uptime SLAs are not a promise that nothing will ever break; they are a statistical ceiling on how often it can. And crucially, a regional SLA says nothing about your availability if your workload lives entirely in the region that failed. Microsoft’s higher availability tiers — the ones that approach 99.99% — are typically contingent on you deploying across availability zones or multiple regions. Run a single-region, single-zone deployment and you have opted, often unknowingly, into the lower tier. The 23 July incident is what the lower tier feels like on a bad day.

Where single-region Azure setups are exposed

In the course of assessing SME Azure estates, the same weaknesses recur — not through negligence, but because workloads are stood up to work and then left alone. The grid below rates how commonly each gap appears and how much it amplifies an incident like this one. A “high” badge means the gap turns a provider’s bad afternoon directly into your business’s bad afternoon.

The first four rows carry “high” badges because they are the ones that decide, before any incident begins, whether a regional fault reaches your users. A workload spread across availability zones or paired regions rides out a single-region event; a workload pinned to one region does not. A second connectivity path keeps you reachable when the first fails; a single ExpressRoute circuit means the outage takes your private line with it. And independent monitoring is the difference between learning about an incident from your own dashboard at 14:45 and learning about it from an angry customer at 16:30. The “low” badge on the final row is not a comment on its importance — named accountability is arguably the highest-value item on the list — but on how directly it maps to a technical failure path. It shapes every other decision rather than opening a specific hole.

What resilient Azure costs a UK SME

Resilience is usually assumed to be expensive, so it is worth grounding in real bands. The figures below are indicative UK monthly ranges for the kind of managed Azure resilience a business of each size typically needs to move from “single region, fingers crossed” to “survives a bad afternoon.” They are illustrative planning bands, not quotes — every estate differs — but they give a realistic sense of order of magnitude, and of how modest the proactive figure looks against the cost of an unplanned outage.

The comparison that matters is not the monthly figure in isolation but the ratio against a single lost afternoon. Five hours of a stalled business — staff idle, orders unprocessed, customers unable to reach you, and in regulated sectors a reporting obligation ticking — routinely runs to thousands or tens of thousands of pounds once you count lost productivity, delayed revenue and recovery effort. Against that, a resilience arrangement that keeps a second region warm and a second connectivity path live is a modest, predictable line item. Resilience is not an expense you hope to justify after an incident; it is the insurance that means the incident never becomes yours.

Reactive versus resilient: two ways to run Azure

The 23 July incident ultimately describes a choice of posture. Most SMEs run Azure reactively — the workload is deployed, it works, and it is only revisited when something breaks. A resilient posture treats the cloud estate as an architecture to be designed, monitored and tested against exactly this class of failure. The difference is not primarily about spending more; it is about deciding, in advance, that a single region’s bad day will not be your bad day.

Read the two columns side by side and the right-hand list is not exotic engineering — it is standard Azure well-architected practice that most SMEs simply never had the time or in-house expertise to put in place. Availability zones, paired regions, geo-redundant backup, dual connectivity and independent monitoring are all native Azure capabilities. The gap between the two columns is rarely budget; it is attention, design and someone whose job is to own the decision. That is exactly the gap a managed Azure partner closes.

How resilient is the typical UK SME tenancy?

If we score a representative single-region, unmanaged SME Azure setup against the well-architected resilience checklist — multi-region or zone redundancy, dual connectivity, independent monitoring, geo-redundant backup, a tested DR runbook — the picture is sobering. Most fall well short, not through a single failure but through the accumulation of sensible-at-the-time defaults. The gauge below reflects a typical starting position; the aim of a managed Azure engagement is to move that needle firmly into the upper band.

A score in the low forties is not the mark of a badly run business. It is the natural resting state of any cloud estate that was migrated to work rather than architected to survive a regional failure. The value of an incident like 23 July is that it turns a vague “we should probably look at our resilience” into a specific, checkable list. Moving from the low forties into the eighties is a matter of weeks of focused work with the right partner — and, importantly, almost none of it requires rebuilding the workload from scratch. Most of it is configuration, redundancy and monitoring layered onto what you already run.

At a glance: the incident in facts

How this connects to the wider 2026 cloud picture

This outage does not stand alone. It is one thread in a summer where UK businesses have been forced, repeatedly, to confront how much of their operation now runs on infrastructure they do not control. The July 2026 Patch Tuesday, with its SharePoint and ADFS zero-days across 622 CVEs, made the same Microsoft stack a security concern in the same month it became an availability concern — two faces of the same dependency. The NCSC and FSB router advisory is the connectivity edge of the story: your resilient cloud is only as reachable as the network path into it, which is why dual connectivity sits so high on the resilience checklist above.

Two further pieces round out the context. The AI-driven threat landscape captured in our coverage of Proofpoint’s finding that 58% of UK ransomware victims paid is a reminder that resilience and security are the same discipline — the geo-redundant backup that survives a regional outage is the same backup that lets you refuse a ransom demand. And the social-engineering lessons from the Scattered Spider TfL sentencing underline that the human and architectural sides of resilience have to move together: the best multi-region design in the world does not help if an attacker talks their way into the tenancy that runs it. A UK SME getting its house in order should treat cloud resilience, patching, connectivity and security as one programme, not four separate fire drills.

Frequently asked questions

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.