On 6 September 2026, four submarine cable systems in the Red Sea were damaged: SEA-ME-WE-4, IMEWE, FALCON GCX and Europe India Gateway. Between them they carry a large share of the traffic between Europe, the Middle East and Asia.

Microsoft recorded the start at 05:45 UTC and told customers that traffic crossing the Middle East might see elevated latency. It also said the thing that matters most about this incident: traffic was not interrupted, because it had been rerouted onto other paths.

Slow speeds and intermittent access were reported in Saudi Arabia, Pakistan, the United Arab Emirates and India. Indian operators said there was no noticeable impact on domestic networks, which have redundancy across many routes.

So four cables were cut and the internet did not go dark. The interesting question is why not — and the second, less comfortable question is what happens next.

The cause is mundane, and that is the point

The International Cable Protection Committee's early analysis points at commercial shipping: most likely a vessel dragging its anchor across the cables.

That is not exotic. Anchors and fishing account for the large majority of cable damage worldwide, and anchor incidents alone are put at roughly 30 percent of global cable faults annually. Cables are cut somewhere in the world routinely — the figure usually quoted for all causes is over a hundred faults a year — and almost none of it reaches the news, because almost none of it is noticed by users.

What made this one visible was concentration. The Red Sea is a chokepoint: a narrow corridor that a great many separate cable systems transit because geography leaves no alternative. Systems that are independent everywhere else are neighbours there. One anchor can therefore reach several at once, which is a different risk from any one cable's reliability.

Rerouting is instant and nearly free. Repair is neither.

Here is the asymmetry the incident exposes.

Rerouting happens in software, in seconds, at a cost of some latency. Networks are built with alternate paths precisely so a fibre cut becomes a routing event rather than an outage. That worked, visibly, at scale, on the day.

Repair happens in the physical world. A cable ship has to be located and contracted, sail to the site, locate the fault, grapple the cable off the seabed, lift it, splice it, test it, and lay it back. Estimates for this incident run from weeks to several months, and the constraints named are not technical:

  • Very few specialised cable repair vessels exist globally. They are a small fleet, contracted across many operators, and they are not idle.
  • Permitting and security clearance, in a region where both are difficult.
  • Weather and sea state.
  • Geopolitical constraints on operating in those waters at all.

So the system is elastic in software and scarce in hardware. You can reroute a packet in milliseconds; you cannot reroute a ship. The datacentre capacity numbers had the same property — the figure that governs is rarely the one in the headline, and here it is not bandwidth, it is berths.

What redundancy actually bought

Worth being precise, because "the internet is resilient" is both true and lazy.

Redundancy did not make the loss free. It converted a hard failure into a degraded one, and it moved the cost from users to operators — who are now paying for more expensive transit on longer paths, and will keep paying until the splices are done. Latency rose. Capacity headroom fell. The next fault, on the remaining paths, now lands on a system with less slack than it had on 5 September.

That is the real exposure. Not this incident, but the window after it.

What to do

  • Ask your providers which physical paths they actually use, not how many. Two carriers can be one cable.
  • Expect elevated latency on Europe to Asia routes for weeks, and treat performance regressions in that corridor as expected rather than as faults to chase.
  • Test failover now, while capacity is reduced, rather than assuming headroom you no longer have.
  • If you run anything latency-sensitive across this corridor, this is the quarter to have a second region.

What is not established

  • Confirmation of the cause. The anchor explanation is the ICPC's early analysis, not a finding.
  • Which vessel, if any, was responsible, and whether it was accidental.
  • A repair timeline. Nobody has committed to one, and the honest answer is that it depends on ship availability and permissions.
  • Whether all four cuts share a single cause, or whether they merely coincide.
  • Total capacity lost, which operators generally do not publish.