Microsoft linked an Azure networking outage to infrastructure servicing activity, affecting hybrid-cloud connections across 18 regions.
The Register reported that Microsoft warned customers using ExpressRoute Gateway, VPN Gateway and Azure VMware Service that they could see degraded or interrupted connectivity, along with some network management failures. Microsoft also said it had paused the infrastructure servicing activity associated with the onset of the event.
The incident began at 20:30 UTC on 30 September 2026. These services are core pieces of hybrid cloud infrastructure because they connect an organisation’s own network or data centre to workloads running in Azure.
ExpressRoute, VPN Gateway and Azure VMware Service were all involved
The disruption centred on three Azure services with different roles. ExpressRoute Gateway connects on-premises networks to virtual networks in Azure. In simple terms, it is one way companies join their own infrastructure to Microsoft’s cloud. Azure VPN Gateway does a similar job by creating a secure tunnel between on-premises systems and Azure. Azure VMware Service is Microsoft’s managed environment for running VMware-based workloads in Azure, which Microsoft presents as a hybrid-cloud option, as The Register described.
Microsoft said customers might experience either degraded service or a full interruption, depending on the component involved. The report also said some affected VPN Gateways saw reduced redundancy rather than a complete loss of connectivity. That distinction matters in practice: reduced redundancy means a service may still work, but with less failover protection if another problem appears before full recovery.
Later status information cited in the report expanded the affected product list to include Azure Firewall, Application Gateways and Web Application Firewall. Those services sit in front of applications or filter network traffic, so their inclusion suggests the incident reached beyond a single connection product, even though the report does not quantify the impact on those additional services.
The outage covered 18 regions, but not every service in every region
According to The Register’s account of Microsoft’s status page, the incident affected 18 Azure regions: West US, West US 3, North Europe, West Europe, France Central, UK West, UK South, 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 effect was not perfectly uniform across all products. The report says Azure VMware Service was not impacted in the last four of those regions: Mexico Central, Germany North, South India and Jio India Central. That is a useful reminder that a cloud incident can be regional and service-specific at the same time. Two customers may both operate in affected regions yet see different outcomes depending on which Azure products they use.
Microsoft reported recovery, but not a confirmed root cause
The available reporting points to an apparent operational link, not a settled explanation. Microsoft’s investigation, as quoted by The Register, “continues to show a correlation between this event and infrastructure operating system servicing activity.” In plain English, Microsoft had enough evidence to connect the outage with maintenance on underlying systems, but not enough to say exactly what failed or why.
That uncertainty is central to the story. A correlation is not the same as a confirmed root cause. The source explicitly says Microsoft did not yet know what happened, or why, at the time of reporting.
On recovery, Microsoft said at 23:13 UTC that it was “seeing continued recovery across impacted ExpressRoute gateways and are monitoring this recovery to confirm that it remains durable.” It also said some supporting network management components had not recovered automatically and were still causing management-operation failures in a subset of regions. Engineers were restoring those components using alternate healthy instances where available, according to the same report.
Later, The Register updated its story to add that Microsoft said it had mitigated the incident and promised more information. Even so, the reported language shows that service restoration and management-plane recovery were not necessarily the same thing. A network path may come back before every admin function or supporting component is fully healthy.
What the incident actually tells us
The strongest conclusion supported by the available reporting is narrow but important: Microsoft saw a correlation between this outage and infrastructure servicing activity, and the disruption reached several services that hybrid-cloud customers rely on to connect on-premises systems with Azure.
For IT teams, that matters because the affected products are not peripheral tools. They are part of the network layer that ties private infrastructure to cloud workloads. The source does not say how specific businesses responded, so it would overstate the evidence to claim broad changes in enterprise buying plans or migration strategy. What it does establish is that an issue associated with cloud servicing activity was able to disrupt connectivity and some management operations across a wide regional footprint.
What readers should watch next is the follow-up Microsoft promised. The open questions are the root-cause explanation, why some supporting management components did not recover automatically, and whether Microsoft describes any servicing changes intended to reduce the chance of a repeat. Until then, this incident is best understood as a reminder that even routine cloud maintenance can affect the network paths and control systems that hybrid deployments depend on.