Multiple simultaneous cuts to undersea fibre-optic cables in the Red Sea near Jeddah have sent latency soaring for Microsoft Azure customers and internet users across South Asia, the Gulf, and beyond, forcing the cloud giant to reroute massive volumes of data onto longer alternate paths. The disruption, first detected around 6 September 2025, knocked out key trunk systems including SEA-ME-WE-4 (SMW4) and IMEWE, and left Pakistan, India, the UAE, and other nations grappling with sluggish web loads, choppy video calls, and delayed cloud operations. Microsoft posted an Azure Service Health advisory acknowledging “higher latency on some traffic that previously traversed through the Middle East,” while insisting that reachability was preserved through swift traffic engineering.

What happened – the operational facts

The cuts were reported near the Saudi port city of Jeddah, a critical landing point where multiple high-capacity cables converge. NetBlocks, a digital rights monitor, named SMW4 and IMEWE as affected, while other reports pointed to additional systems like FALCON and GCX regional feeders. The precise cause remains unconfirmed, but the event coincided with heightened maritime tension in the Red Sea, where Houthi rebels have previously targeted shipping.

Microsoft’s advisory, issued via Azure Service Health, told customers they “may experience increased latency” on traffic previously routed through the Middle East corridor. The company said it had rerouted affected flows onto alternative network paths and would provide daily updates as repairs progressed. Third-party telemetry from Cloudflare Radar and NetBlocks confirmed route changes and higher round-trip times in the region.

End-user impact was immediate. Consumer complaint trackers and social media posts spiked with reports of buffering video streams, broken VoIP calls, and sluggish app performance. For enterprises, the event translated into elongated backup windows, higher API latencies, and increased retry rates for cross-region replication jobs.

Why the Red Sea matters: geography of a digital chokepoint

The Red Sea corridor is the shortest physical path linking large parts of Asia with Europe. By some estimates, nearly 17% of global internet traffic transits cables that pass through this narrow stretch of water and onward through Egypt. That concentration turns a handful of cable faults into a major performance phenomenon for cloud services and internet users worldwide.

Physical fragility compounds the risk. Subsea cables are vulnerable to ship anchors, fishing gear, seismic activity, and deliberate sabotage. Repairing a severed cable requires locating the fault, dispatching a specialised vessel, retrieving cable ends, splicing, and testing – a process that can take days in ideal conditions but often stretches to weeks or months when geopolitical tensions limit access to the repair site.

How cable cuts become cloud incidents (technical anatomy)

Cloud services may be logically distributed, but their performance is tethered to the physical transport layer. The chain reaction unfolds in a clear sequence:

  • A subsea segment is damaged, instantly reducing capacity on the primary corridor.
  • Border Gateway Protocol (BGP) withdrawals and operator traffic-engineering cause upstream networks to recompute paths.
  • Traffic shifts to remaining links that are often longer or already heavily utilised.
  • Longer physical routes increase propagation delay (higher RTT). Crowded alternatives introduce queuing delay and packet loss.
  • Latency-sensitive workloads – VoIP, video conferencing, synchronous replication, high-frequency APIs – and “chatty” services show the effects first.

Microsoft’s advisory reflected this sequence precisely. Reachability was maintained, but latency on the rerouted flows rose because the network had to use longer detours, and existing capacity had to absorb the redirected traffic. This is why operators characterise such incidents as performance-degradation events rather than platform outages.

Who and what was affected

Regions and networks

Measurable slowdowns and routing changes hit:

  • South Asia (India, Pakistan)
  • Gulf countries (UAE, Saudi Arabia)
  • Parts of Africa and Europe that rely on the same east–west trunk paths

Specific ISPs and carriers reported degraded performance during peak hours. Cloud-dependent enterprises with cross-region replication or synchronous services experienced elongated transfer times and higher error rates.

Cloud and enterprise workloads

Typical symptoms included:

  • Higher API and transaction latency for cross-region calls
  • Slower backups and replication windows across continents
  • Video/VoIP degradation: packet loss and jitter affecting call quality
  • Elevated retry/time-out rates for chatty protocols and synchronous services
  • Regional inconsistency: some geographies unaffected while specific routes suffered significant slowdowns

Cloud control-plane operations (management APIs) were less affected because they often use different ingress/egress points, allowing providers to avoid a full outage while data-plane traffic endured degraded performance.

Attribution and geopolitical context

Multiple outlets noted that the cuts occurred during a period of heightened maritime tension in the Red Sea. Some reports referenced the Houthi rebel campaign that has targeted shipping and maritime infrastructure. However, definitive attribution of these specific cuts requires forensic confirmation from cable operators and neutral investigators. Until operators publish formal root-cause analyses, any single-actor attribution must be treated as provisional.

What Microsoft and carriers did to mitigate

  • Traffic rerouting and rebalancing: Microsoft rerouted Azure data-plane traffic away from damaged segments onto alternate paths and rebalanced capacity while monitoring performance. Traffic not traversing the Middle East corridor remained unaffected.
  • Carrier coordination: National operators provisioned temporary transit where feasible and worked with peers to absorb redirected flows. Some issued customer advisories warning of peak-hour degradation.
  • Independent monitoring: NetBlocks, Cloudflare Radar, and others published telemetry showing route changes, higher RTTs, and throughput reductions, confirming the disruption’s scope.

Practical guidance for IT teams, Azure administrators, and Windows-centric enterprises

This incident should be treated as a live resilience test. The following checklist prioritises immediate, practical steps.

Immediate checklist (first 24–72 hours)

  • Monitor Azure Service Health and subscription alerts continuously; subscribe to automated notifications for affected regions.
  • Map critical flows: identify which applications, ExpressRoute circuits, peering sessions, or VPNs rely on east–west transit through the Red Sea corridor. Prioritise remediation for mission-critical paths.
  • Harden client-side resiliency: increase timeouts, implement idempotent retries, and add exponential back-off to avoid amplifying congestion. Convert chatty syncs to async where possible.
  • If you use ExpressRoute or dedicated transit, engage your carrier and Microsoft account team; ask about targeted routing, temporary transit capacity, and service credits if SLAs are affected.
  • Defer non-critical cross-region transfers (large backups, non-urgent data migrations) until routing stabilises or schedule them for off-peak windows.

Short-term architectural adjustments (days to weeks)

  • Use regional caching and CDN edge-delivery to localise traffic and reduce cross-continent transfers.
  • Evaluate multi-region active-active deployments that avoid the affected corridor for inter-region replication when feasible.
  • For latency-sensitive services, consider temporarily moving replication endpoints to regions that do not require Red Sea transit.
  • Revisit SLA exposure modelling: quantify how much traffic traverses the affected corridor and calculate potential business impact under degraded throughput or raised latency.

Medium-term strategic changes (weeks to months)

  • Diversify network paths: increase peering and transit diversity to reduce reliance on a single geographical chokepoint.
  • Negotiate peering and transit contingency clauses with carriers and cloud providers for crisis capacity.
  • Incorporate subsea-cable risk into business continuity planning and tabletop exercises.
  • Consider hybrid or multi-cloud replication for mission-critical workloads that must survive a corridor failure without large performance impacts.

Broader implications: technical, commercial, and geopolitical

For cloud reliability engineering

This incident demonstrates that logical redundancy (multiple regions, automatic failover) must be coupled with physical route diversity to deliver expected performance under real-world failures. Cloud architects increasingly need to treat network geography as a first-class reliability vector.

For telecom operators and governments

The event strengthens the case for investment in alternate submarine routes, accelerated repair capacity (more specialised cable ships), and cooperative international protection of critical infrastructure. It also underscores the value of transparent, timely operator reporting so enterprises can make informed mitigation choices.

For enterprise risk and continuity planning

Organisations whose business continuity assumes low-latency cross-region replication or real-time ties between continents must now incorporate subsea corridor failure modes into recovery plans and SLAs. The cost of inaction is not just temporary slowdown – financial and reputational harm can follow when trading platforms, communications, or critical customer-facing systems are affected.

Strengths and weaknesses of the response so far

Notable strengths

  • Rapid detection: Public monitoring services and carrier telemetry identified route changes quickly, allowing operators and cloud providers to coordinate mitigation.
  • Fast traffic engineering: Major cloud providers, particularly Microsoft, moved to reroute traffic and reweight backbone flows, preserving reachability while reducing the risk of total outages. Microsoft’s Service Health messaging was clear and operationally focused.
  • Visibility for customers: Microsoft committed to daily updates and advised customers about expected higher latency, enabling IT teams to take short-term action.

Potential weaknesses and risks

  • Attribution uncertainty: Premature public attribution to any actor without operator confirmation risks politicising infrastructure management and may complicate repair access or insurance claims. Final RCAs will be needed to assign responsibility.
  • Repair logistics: The limited global fleet of repair vessels and permissioning in contested waters means physical restoration can take materially longer than initial network mitigation – sustained impacts are plausible.
  • Concentration risk: Physical cable clustering at specific landing sites remains a systemic vulnerability; logical redundancy in the cloud does not automatically translate to physical path diversity.

What to watch next

Keep a regular watch on these indicators until operators confirm repairs and telemetry stabilises:

  • Azure Service Health advisories for affected regions and specific services.
  • NetBlocks and Cloudflare Radar route/latency telemetry for region-level trends.
  • Carrier bulletins from SMW4 / Tata Communications, IMEWE consortium statements, and repair-ship position updates reported by operators.
  • Application-level KPIs: API latency (p50/p95/p99), consecutive time-outs, TCP retransmit rates, and sustained error rates for replication or backup jobs.

Final assessment

The Red Sea incident is a timely reminder that cloud services, while resilient in many respects, remain subject to the physics and geopolitics of global transport infrastructure. Operators and IT teams should treat submarine cable corridors as a measurable risk factor and adapt both operational runbooks and architectural choices accordingly.

In the immediate term, follow Azure Service Health, coordinate with carriers and Microsoft account teams, and implement client-side resiliency measures. Over the medium term, invest in route diversity, robust CDN/caching strategies, and multi-region designs that explicitly avoid single-corridor dependencies for latency-sensitive services. For policy and industry stakeholders, the event reinforces the need for better international coordination on cable protection, faster access for repair operations, and investment in alternative routes that reduce concentration at single chokepoints.

This incident will remain an operational story until operators confirm the full list of damaged systems and repair timelines. Organisations that treat network geography as a core resilience consideration will be best placed to weather the coming weeks as traffic engineering and maritime repair efforts progress.