Infrastructure

Network Outage: Subsea Cable Cuts Hit Philippine Internet

Published October 5, 2026 · DNS Benchmark Pro Editorial · Reading time: 7 minutes

The most instructive network outage of the past week produced no incident page, no CVE and no breach notification. At roughly 9:30 p.m. local time on Thursday 2 October 2026, two of the submarine cable segments carrying Philippine traffic to the rest of Asia stopped passing packets. Subscribers of Globe, PLDT and Converge ICT — along with campus networks such as UP Diliman — saw exactly what capacity loss looks like from the user side: pages that loaded eventually, video that buffered, API calls that timed out on retry, and the persistent suspicion that something was wrong with their own equipment.

What failed, and what it cost in capacity

Philippine Department of Information and Communications Technology (DICT) Secretary Henry Aguda put the lost capacity at roughly 300Gbps across the affected links, and said carriers had enough provisioned headroom to absorb it. That statement is both reassuring and the whole story: the country did not lose connectivity, it lost margin.

Why a capacity event is harder to diagnose than a hard failure

When a router dies, monitoring screams. When 300Gbps of transit disappears from a country that still has working paths to the internet, nothing goes red. BGP reconverges, traffic lands on whatever capacity remains, and the symptom is congestion: queueing delay, retransmissions, and a long tail of slow requests. Every dashboard built around reachability reports green.

That is why this class of network outage generates a flood of misdirected support tickets. Users blame their router, admins blame the application, and the application team blames the database, because the actual constraint — a saturated international path three autonomous systems away — is invisible from every one of those vantage points. The only telemetry that catches it early is latency and loss measured continuously against destinations you do not control.

The geography matters too. Services hosted inside the Philippines were fine throughout; local government portals and domestic banking stayed responsive. The degradation was specific to traffic crossing the damaged segments, which in practice means most SaaS, most public cloud regions and most CDN origins. For an enterprise running a Manila office against a Singapore cloud region, this was a severe event. For the same enterprise running a locally hosted ERP, it was invisible.

How carriers reroute, and what it costs in network latency

Rerouting is less dramatic than it sounds. Large carriers buy capacity on several cable systems and hold IP transit with multiple upstreams precisely so a single segment failure becomes a traffic-engineering problem rather than an outage. Globe said it moved mobile, broadband and corporate traffic onto redundant international links the same night; PLDT and Converge both confirmed shifting affected traffic onto other submarine cable systems.

The price is paid in path length. A Manila-to-Singapore flow that normally takes a direct southbound segment may end up routed north and back down, or across a longer western path. The resulting change in network latency — often tens of milliseconds — is trivial for a file transfer and punishing for anything chatty. TLS handshakes, database round trips, and synchronous microservice calls multiply added round-trip time by the number of exchanges, which is how 40ms of extra path delay becomes a two-second page load.

Encrypted DNS deserves a mention here because it sits on the critical path of every new connection. A resolver reached over DNS over HTTPS inherits the same degraded path as the rest of your traffic, plus connection setup. When international capacity is constrained, a cold DoH lookup can add noticeably more delay than the plaintext UDP query it replaced — an argument for local caching and sensible TTL handling rather than for abandoning encrypted transport.

Sabotage, anchors and the attribution problem

Asked directly about sabotage, Aguda kept it open: one scenario among several, too early to say, with natural causes and equipment failure equally plausible. That is the correct posture, and it is also the recurring difficulty with subsea faults. Most cable damage worldwide is caused by fishing gear and ship anchors in shallow water. Deliberate damage looks much the same on a fault-location trace, and intent is usually established by what was on the surface at the time — not by the cable itself.

What makes the question more than academic is frequency. Two segments on different routes failing within one window invites suspicion by itself, and the past two years of incidents in the Baltic, the Red Sea and around Taiwan have made subsea infrastructure a standing agenda item for national security teams. For IT leaders the practical conclusion does not change with the verdict: the cable is a single point of failure you do not own, cannot monitor and cannot repair.

What IT security and infrastructure teams should take from this

1. Map your actual egress paths. Know which subsea systems your traffic to each cloud region depends on. Two providers that both land on the same cable are not redundancy.
2. Monitor latency and loss, not just uptime. Synthetic checks from the affected region to your real endpoints catch capacity events that availability probes miss entirely.
3. Keep resolution local and cached. Recursive resolution that crosses an international link during congestion compounds every other delay. Validate DNS server performance from inside the affected region, not from headquarters.
4. Pre-write the degradation playbook. Which batch jobs pause, which replication throttles, which features degrade gracefully — decided in advance, not at 2 a.m.
5. Treat capacity loss as an IT security event too. Congestion masks volumetric activity: a DDoS attack and a cable cut produce similar user-facing symptoms, and attackers are opportunistic about noisy windows.

The DNS security angle: resolution crosses the same cables

Name resolution is the first thing a degraded path breaks and the last thing anyone measures. If your recursive resolver forwards to an upstream in Singapore and the Singapore segment is congested, every cache miss inherits that penalty before a single byte of application traffic moves. Worse, timeouts push resolvers to secondary servers, which changes answer sources and quietly alters which CDN edge or cloud region clients are steered to — a DNS security and performance concern at once.

Running our free DNS benchmark and network diagnostic tool from an affected site answers the question support desks cannot: is resolution slow because the resolver is struggling, or because the path to it is saturated? If you are evaluating encrypted transport, our guide to DNS over HTTPS and DNS over TLS covers how connection reuse and caching change the picture when capacity is tight.

Industry impact: resilience is a routing problem, not a buying problem

Set this beside the Kiteworks precautionary shutdown we covered on 26 September. That outage was a deliberate control decision — a vendor pulling servers offline to contain a zero-day vulnerability. This one was physical, unplanned and entirely outside anyone’s administrative control. Yet both landed on enterprise teams the same way: a dependency they did not operate stopped behaving, and the quality of their response came down to whether they had measured the dependency beforehand.

The encouraging part of this network outage is how ordinary the recovery was. Carriers had pre-provisioned alternate capacity, moved traffic within hours, and restored the segment in under 48 hours without waiting on a repair vessel. That is resilience engineering working as designed. The uncomfortable part is that the margin absorbing the failure is finite, shared, and shrinking as traffic grows faster than new systems land.

For anyone running server infrastructure across borders, the lesson is unglamorous and durable: redundancy you have not traced to the physical layer is an assumption, not a control. Two carriers, two clouds and two regions can still be one cable.

Sources

• Newsbytes.ph — PH-SG subsea cable cut disrupts Internet as telcos reroute traffic
• Newsbytes.ph — Internet services normalize after PH-Singapore cable cut
• GMA News — Slow, intermittent internet in PH linked to submarine cable outage
• GizGuide — DICT: Submarine cable outage triggers slow internet across the Philippines

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The cable landing station photograph is by Wikimedia Commons user Dirk1981, licensed CC BY-SA 4.0; the DICT logo is a public-domain reproduction of an official government mark, via Wikimedia Commons; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated. DNS Benchmark Pro is not affiliated with Globe Telecom, PLDT, Converge ICT or the Department of Information and Communications Technology.