Microsoft's Azure Maintenance Mishap Knocked Out UK South and UK West Connectivity for Seven Hours

At 20:30 UTC on 30 September 2026, Microsoft began warning users of ExpressRoute Gateway, VPN Gateway and Azure VMware Service that they might experience degraded or interrupted network connectivity, and struggle to perform some network management operations. 18 Azure regions were affected, including both UK regions — UK South and UK West. By 03:30 UTC on 1 October, roughly seven hours later, Microsoft said it had mitigated the incident, while simultaneously widening the list of affected products to include Azure Firewall, Application Gateways and Web Application Firewall.

The cause is the part worth reading twice. Microsoft’s status page said it had “paused the infrastructure servicing activity associated with the onset of this event”, and its investigation “continues to show a correlation between this event and infrastructure operating system servicing activity”. In plainer terms: the strong indication is that Microsoft’s own planned maintenance broke it. At the time of writing the company had not explained exactly what went wrong or committed to a root cause. That combination — mitigated, self–inflicted, unexplained — is an uncomfortable place for customers to be, and it points at a structural issue that has nothing to do with Microsoft specifically. These three services are the services that join an on–premises network to a cloud one. A business running everything in Azure was largely unaffected. A business running everything in its own server room was entirely unaffected. The organisations that lost connectivity were the ones doing the thing every migration guide recommends: running a hybrid estate.

What broke, and what those services actually do

The three services named at the outset are not peripheral. ExpressRoute Gateway connects on–premises networks to virtual networks in Azure and is a core building block of hybrid cloud — typically a private circuit rather than a path over the public internet, chosen precisely because it is supposed to be more reliable. Azure VPN Gateway creates a secure tunnel between on–premises infrastructure and Azure, and is the usual choice for smaller deployments or as a backup to ExpressRoute. Azure VMware Service lets businesses run VMware–based hybrid cloud workloads in Azure, which for many organisations means production virtual machines lifted from their own data centre.

The impact was not uniform, and Microsoft’s own updates are careful about this. By 23:13 UTC on 30 September it reported “continued recovery across impacted ExpressRoute gateways” and noted that some affected VPN Gateways had experienced reduced redundancy rather than a complete loss of connectivity. That distinction matters for anyone reconstructing their own experience: a customer whose tunnel stayed up may have been running on a single path for several hours without realising it, which is a different and quieter kind of exposure than an outright failure.

The second category of failure is the one that causes disproportionate frustration. Microsoft said “some supporting network management components have not recovered automatically and are contributing to management operation failures in a subset of affected regions”, with engineering teams restoring them via alternate healthy instances. Read that alongside the original warning that customers might “struggle to perform some network management operations” and the shape becomes clear: this was a management plane problem as well as a connectivity one. Customers could not necessarily reconfigure their way around the fault, because the tooling required to reconfigure was itself impaired.

The 18 affected regions were UK South, UK West, West US, West US 3, North Europe, West Europe, France Central, Switzerland North, Southeast Asia, East Asia, Japan West, Korea Central, South Africa North, UAE North, Mexico Central, Germany North, South India and Jio India Central. The geography is worth noting because of what it rules out. This was not a regional power event, a data centre problem or a submarine cable fault. A list spanning four continents with no obvious physical connection is the signature of something propagating through a process rather than through infrastructure — which is consistent with Microsoft’s own statement about servicing activity.

And at the mitigation update at 03:30 UTC on 1 October, the list of affected products grew to include Azure Firewall, Application Gateways and Web Application Firewall. Expanding the blast radius at the same moment as declaring the incident mitigated is not a contradiction — understanding of scope routinely lags recovery — but it does mean customers assessing their own impact should not assume the first product list was complete.

Seven hours, as Microsoft reported them

The timeline below follows Microsoft’s own status updates. All times are UTC; the UK was on British Summer Time, so local times were an hour later.

The single most consequential fact in that timeline is the clock. 20:30 to 03:30 UTC is 21:30 to 04:30 BST — which is to say the entire incident fell outside UK working hours. A great many UK organisations will have experienced this as nothing at all, or as a handful of failed overnight batch jobs nobody has yet investigated. That is not resilience. It is the timetable. Had the same servicing activity gone wrong at 09:30 UTC on a Tuesday, the identical fault in the identical 18 regions would have been a very different day for every hybrid estate in the country, and the only variable would have been the hour.

What actually survives a provider–side failure

The chart below is an indicative planning model — not measured data — ranking architectures by how well they withstand this specific class of event: the provider’s own servicing activity impairing hybrid connectivity across many regions at once.

The second and third rows are where most well–architected hybrid estates sit, and they score poorly here for one reason: both forms of redundancy are inside the same provider. A VPN Gateway standby protects against an ExpressRoute circuit failing. Two Azure regions protect against a regional event. Neither protects against servicing activity that reaches 18 regions including both UK ones, because the shared element is the platform’s own operational processes. This is exactly the argument the networking industry makes about physical path diversity, transplanted to the cloud: a second path is only worth what its independence from the first is worth.

The top rows are not recommendations so much as a statement of what genuine independence costs. Replicating critical services to a second provider is expensive, operationally complex and introduces its own failure modes, and for most UK SMEs it would be a poor trade. The fifth row is the realistic target for most organisations and the one worth thinking about seriously: can the business function, in a degraded but viable way, for a few hours with no connection to the cloud? That is a design question with cheap answers — local caching, offline–capable applications, a printed list of what to do — and it converts a seven–hour outage from a crisis into an inconvenience without requiring a second cloud platform.

Seven hours of twenty–four, and which seven

Express the duration as a share of a day and the thing that determined the severity of this incident for UK organisations becomes visible.

There is a planning conclusion in that, and it is not a comfortable one. The impact a UK business felt from this incident was determined almost entirely by when it happened rather than by how it was architected. Two organisations with identical hybrid designs, one with overnight batch processing and one without, had completely different nights. Neither made a better decision than the other. The one that noticed nothing has not validated its architecture; it has simply not been tested yet.

Which points at the right way to use an incident like this. Rather than concluding you were unaffected and moving on, the useful exercise is counterfactual: if this had started at 09:30 UTC on a Tuesday, what would have stopped working, and for how long? That question costs nothing to answer and produces a list most organisations have never written down. It will typically include things nobody classifies as cloud–dependent — a file share that is actually in Azure, an authentication path that traverses the tunnel, a line–of–business application whose database sits on the other side of the link, a backup job, a reporting feed, a VoIP service.

The management plane detail deserves its own weight in that assessment, because it undermines a common assumption in continuity planning. Microsoft noted that supporting network management components had not recovered automatically and were contributing to management operation failures. The implication is that during the incident, customers who wanted to change something — fail a route over, reconfigure a gateway, spin up an alternative path — may have found that they could not. Most continuity plans assume that the operator retains control and only the service is impaired. A control–plane outage breaks that assumption, and a runbook whose first step is “log into the portal and reconfigure” is not a plan under those conditions.

Where hybrid estates are exposed

The rows below reflect where this risk typically sits in a UK organisation running a hybrid estate, with badges indicating how much attention each usually needs.

The third row is the one that turns a connectivity problem into a total stoppage, and it is extremely common in organisations part–way through a cloud migration. If domain controllers are on premises and cloud workloads authenticate back across the tunnel — or the reverse — then losing the link does not degrade one system, it stops everything that requires a login on one side of it. Authentication is the dependency that propagates furthest and is least often mapped, because it is invisible when working.

The seventh row connects directly to Microsoft’s own clarification that some VPN Gateways suffered reduced redundancy rather than outright failure. An organisation with no visibility of redundancy state cannot distinguish “working” from “working with no margin left”. Those are very different positions, and the second one is where a second, unrelated fault becomes an outage. Monitoring that reports path state rather than only reachability is the difference between knowing and guessing.

What addressing this costs

The bands below are indicative planning figures for UK businesses reviewing and improving hybrid cloud resilience — not quotes. The variable that moves them most is how many business processes actually traverse the link.

The final row is free and it should come first. Most organisations reading this were not materially affected, which creates a strong temptation to do nothing — and the honest response to that temptation is that doing nothing may well be correct, but it should be a decision rather than a default. Writing down what would have broken at 09:30 on a Tuesday takes an afternoon and tells you whether the rows above are worth their cost. Without that list, any spending decision here is guesswork, and any decision not to spend is luck dressed as judgement.

Two ways to run a hybrid estate

The honest summary is that the right–hand column is mostly knowledge rather than expenditure. The dependency map, the authentication review, the redundancy monitoring and the runbook rewrite are analysis and configuration. Only genuine path independence costs real money, and for many organisations it will not be justified — which is a legitimate conclusion to reach, provided it is reached after writing the list rather than instead of writing it. What is not defensible is the last item in the left–hand column: treating an incident that happened while everyone was asleep as evidence that the architecture works.

What this says about hyperscaler maintenance risk

It would be easy, and wrong, to read this as a story about Azure being unreliable. Hyperscale platforms deliver availability that essentially no UK SME could achieve in–house, and the honest comparison is not between this incident and perfection but between this incident and the equivalent risk in a self–managed estate — where maintenance also goes wrong, rather more often, with nobody publishing a status page about it. The useful conclusion is narrower: the shape of cloud risk differs from the shape of on–premises risk, and continuity planning that was designed for the latter does not automatically cover the former.

Specifically, a self–managed estate fails in ways that are local, visible and under your control to fix. A cloud platform fails in ways that are simultaneous across many regions, invisible in origin, and entirely outside your control to fix — you can only wait, or fail over to something that does not depend on the same provider. A list of 18 regions spanning four continents with no physical connection between them is a failure mode that simply has no on–premises analogue, and it is the one that in–provider redundancy does not address. That is why both UK regions going down together is the most instructive detail in the whole incident: the geographic separation customers are encouraged to buy was irrelevant to the fault that occurred.

There is also a transparency point worth making fairly. Microsoft published updates as the incident progressed, clarified the difference between lost connectivity and reduced redundancy, acknowledged that management components had not recovered automatically, and has stated a correlation with its own servicing activity rather than attributing it elsewhere. That is more candour than many providers manage. The outstanding gap is the root cause, and until it is published customers cannot assess recurrence risk — which is the single thing they need in order to decide whether to change anything. A mitigated incident with an unexplained cause is a resolved outage and an open question.

For organisations thinking about this through a Cyber Essentials or wider assurance lens, the relevant discipline is the same enumeration this series keeps returning to. You cannot assess the impact of losing a connection you have never mapped. An estate inventory that records which workloads sit where, which dependencies cross the boundary, and who owns each one is the prerequisite for every judgement in this article — and it is the same artefact that makes a vulnerability advisory a twenty–minute scoping exercise rather than a two–hour hunt.

The story at a glance

This story connects to several we have covered recently, and the thread is shared failure modes. LINX’s LON2 fabric passing 1Tbps is the essential companion piece — an internet exchange spending real money on a deliberately disaggregated second fabric specifically so that a software fault or a bad configuration push cannot land on both paths at once. That is precisely the property ExpressRoute and VPN Gateway do not have relative to each other, and the networking industry worked this out some time ago. The JadePuffer attackers hijacking Azure identities is the same platform viewed through a security lens, and makes the parallel argument that a backup sharing a credential with production is not really a backup. The actively exploited Citrix NetScaler flaws concern the appliances many organisations use to reach cloud estates. The Kiteworks shutdown warning is another instance of a supplier event forcing a decision customers had no information to assess. And Ofcom’s AI ground rules for telecoms speak to what happens when you need to reach a human at a very large provider.

Frequently asked questions

CloudSwitched

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