/// article

Philippines to Singapore Internet Slowdown: Investigating What Happened on October 2, 2026

By lordfrancs3

Examining the PH-SG routing degradation, possible C2C involvement, subsea cable maintenance, and why some websites worked while others failed. On the afternoon of October 2, 2026, I noticed something unusual while working with several servers. My Internet connection appeared normal. Websites were loading, and I was not seeing any obvious problem with my local connection. But my servers in Singapore were behaving differently. SSH sessions became increasingly laggy. Commands took longer to respond, and some connections eventually disconnected. At first, I wondered whether there was a problem with the Singapore servers themselves. I then checked a staging server we host in Malaysia. The connection was perfectly fine. That immediately changed how I looked at the problem. Philippines | +------> Malaysia | Normal | +------> Singapore High latency Lag Disconnects If my Internet connection were the problem, I would expect both destinations to show similar symptoms. They did not. My initial suspicion was that something might be happening along the international route between the Philippines and Singapore. Later that day, I saw a post describing almost exactly what I was experiencing: “We’re noticing a possible C2C issue affecting SG-PH / HK-PH routes, with some sites not loading while others are working normally.” That caught my attention because it closely matched what I had already been seeing. Some destinations worked normally. Singapore did not. So I started investigating. The First Clue Was the Destination The Malaysia comparison was important because it helped separate a local Internet problem from a destination-specific or international routing problem. PH -> Malaysia Normal Stable SSH No noticeable connection issue PH -> Singapore High latency Lag Connection instability SSH disconnects If my router, workstation, or local Internet connection had been the main problem, I would normally expect problems across more than one overseas destination. Instead, the behavior changed depending on where the traffic was going. That pointed farther upstream. Possible causes included: international transit congestion submarine cable capacity problems BGP rerouting upstream carrier issues congestion on alternate routes regional peering problems This also connects with a concept we previously discussed on PinoyLinux. Geographic proximity does not guarantee a better network path. Routing policy, peering, available capacity, and the actual path between networks can matter more than physical distance. This idea is covered in our DNS steering series, particularly Latency, Geography, And Network Distance: What DNS Can And Cannot Know. At this stage, however, what I had was still an observation. I needed independent network data. Independent Measurements Showed Abnormal PH-SG Latency The strongest supporting evidence came from CableStatus. At 07:00 UTC on October 2, or around 3:00 PM Philippine time, CableStatus reported a Philippines-Singapore transit delay advisory based on RIPE Atlas measurements. The results showed: Route Recent baseline Observed latency Philippines to Singapore ~53 ms ~177 ms Malaysia to Singapore ~11 ms ~22 ms For the PH-SG measurement, CableStatus reported data from 28 independent RIPE Atlas anchors. That placed average Philippines-to-Singapore latency at more than three times its recent baseline. Source: CableStatus, Philippines-Singapore Corridor CableStatus is careful about what this means. It describes the event as a telemetry-inferred transit delay, not confirmation that a particular submarine cable failed. That distinction is important. The measurements tell us: Something abnormal was happening along the Philippines-Singapore network path. They do not tell us: A specific submarine cable was definitely cut. That requires separate evidence. The Measurements Matched What I Had Already Seen What made the CableStatus data particularly interesting was how closely it matched my experience. Before I saw the wider reports: Malaysia = working normally Singapore = slow and unstable Later, independent measurements showed that Philippines-Singapore latency had risen sharply. This did not prove the cause, but it gave much stronger support to the idea that my Singapore servers were not the source of the problem. The route toward Singapore had become the more likely suspect. Regional Subsea Cable Work Was Already Happening Another important piece of evidence came from Akamai Service Status. Akamai reported scheduled upstream provider maintenance along network routes connecting Singapore, Hong Kong, and Japan. According to Akamai, the maintenance window ran from September 18 through October 3, 2026. Akamai warned that users in affected regions could experience increased latency during peak traffic periods. More importantly, another Akamai incident update stated that connectivity problems in the APAC region were likely caused by: upstream congestion related to unexpected maintenance on subsea cables A later update said the upstream carrier continued maintenance on impacted submarine cables and that intermittent impact could continue until repair work was completed. Source: Akamai Service Status This does not prove that Akamai’s maintenance event caused the PH-SG slowdown I experienced on October 2. But it tells us something important. Submarine cable capacity and upstream routing around major Asian hubs were already under pressure during the same period. That becomes relevant when traffic needs to move away from its normal path. Why Maintenance on One Route Can Affect Another International networks usually have more than one possible path. If the preferred path becomes unavailable or loses capacity, traffic can move to another route. That redundancy is important. But alternate routes do not have unlimited capacity. Imagine this simplified situation: Normal: Philippines | +------------------> Singapore Primary path If that path becomes unavailable: Philippines | +----> Alternate carrier | +----> Regional hub | +----> Singapore Connectivity remains available. But now the alternate route must carry traffic it normally would not handle. If enough traffic is moved onto it, users may begin seeing: Higher latency | Packet loss | TCP retransmissions | Slow applications | SSH / VPN instability | Timeouts This can make an international routing problem look like an Internet connection that only works sometimes. Then Reports Started Mentioning C2C As reports circulated, one name repeatedly appeared: C2C. C2C stands for City-to-City. It is an intra-Asia submarine cable system that forms part of the larger EAC-C2C network. According to Submarine Networks’ C2C Cable System Overview, C2C uses a dual-ring design. Its northern ring links: Japan Korea China Taiwan Hong Kong the Philippines Its southern ring links: Hong Kong the Philippines Singapore A simplified view of the southern portion looks like this: Hong Kong | | +-------+-------+ | | | | Philippines ---------+ | | Singapore The cable has landing points in the Philippines and Singapore, among other locations. Source: C2C Cable System Overview, Submarine Networks Who Owns EAC-C2C? Telstra International confirms that it operates wholly owned EAC and C2C submarine cable systems. Its network information describes C2C as an intra-Asia cable connecting major Asian business hubs, including the Philippines, Singapore, Hong Kong, Japan, Korea, and Taiwan. Telstra also states that its Philippine infrastructure connects its EAC and C2C submarine cable landing stations. Sources: Telstra International Wholesale Network Telstra Expands Business Offerings in the Philippines This made the C2C reports technically plausible because the cable topology corresponds closely with the PH-SG and PH-HK routes users were discussing. Was the C2C PH-SG Segment Actually Down? This is where we need to separate what we know from what we suspect. Reports circulating among Philippine Internet users and network customers referred to a possible problem on the C2C PH-SG route. Those reports fit what I experienced. They also fit the independent PH-SG latency measurements. The physical network topology also makes C2C a reasonable candidate. However, at the time of writing, I had not found a public Telstra incident notice explicitly saying: The physical C2C Philippines-Singapore submarine cable segment has been cut or is completely down. That means we should avoid presenting that as established fact. What the evidence supports We can reasonably say that: Philippines-to-Singapore connectivity was significantly degraded. Independent RIPE Atlas measurements showed unusually high PH-SG latency. Philippine users reported problems reaching some overseas destinations. My own Singapore connections became slow and unstable while Malaysia remained usable. Regional submarine cable maintenance was independently documented. C2C physically connects the Philippines, Singapore, and Hong Kong. What remained unconfirmed We could not yet independently confirm that: the physical C2C PH-SG cable had been cut the entire C2C PH-SG segment was completely offline C2C alone caused the October 2 incident Until an authoritative carrier or cable operator confirms the exact fault, the safer wording is: Possible C2C involvement in a wider PH-SG international routing or capacity problem. Why Some Websites Worked While Others Failed One of the most confusing parts of the incident was that the Internet did not appear completely broken. Some websites loaded normally. Others were slow. Some did not load at all. That actually makes sense when you look at how Internet routing works. Your ISP does not send every Internet connection through one international path. Traffic can follow different routes depending on: the destination network ISP peering upstream transit providers BGP advertisements CDN infrastructure available submarine cable capacity routing policy locally cached content A simplified example looks like this: +--> Philippine CDN | WORKING | Philippine ISP ----------+--> Japan / US route | WORKING | +--> Malaysia | WORKING | +--> Singapore | X degraded | alternate path | congestion | latency / loss A website served through infrastructure inside the Philippines might never use the affected international route. Another service may depend heavily on Singapore. Another Singapore-hosted service may use a completely different carrier or cable path and remain reachable. This is why two overseas websites can behave very differently even when accessed from the same Internet connection. This Connects With DNS Steering We previously discussed this concept in DNS Steering 101: How Authoritative DNS Influences Traffic Direction. DNS steering can return different service endpoints based on signals such as: country network ASN health policy regional preference For example: Philippine requester | v Authoritative DNS | +----> Manila endpoint | +----> Singapore endpoint | +----> Tokyo endpoint But the important part is that DNS selects an endpoint. It does not control every network hop between the user and that endpoint. So a service can correctly choose Singapore based on geography while the actual Philippines-to-Singapore network path is temporarily performing poorly. That is one reason network distance matters more than simple geographic distance. Why Google, Facebook, or Other Large Services May Still Work Large Internet platforms usually operate distributed infrastructure. They may have: local caches direct ISP peering regional edge nodes multiple transit providers anycast networks several regional data centers multiple fallback paths A request from the Philippines might therefore be answered from infrastructure located locally or through a route that does not depend on the affected PH-SG path. This creates a common troubleshooting mistake. A user opens Facebook successfully and concludes: “My Internet is working.” Technically, that may be true for the path to Facebook. It says very little about the path to a server in Singapore. The better question is: “Which destinations are working?” DNS Steering Can Help, But It Has Limits Suppose an application operates regional endpoints: Manila Singapore Tokyo Under normal conditions: PH users -> Singapore If Singapore becomes unsuitable: PH users -> Tokyo A DNS steering system can influence future connections by returning another endpoint. This concept is discussed in Health Checks In DNS Steering: From Origin Status To Answer Policy. But this incident illustrates an important problem. A server can be completely healthy while the network path toward it is unhealthy. For example: Singapore server: CPU: Normal Memory: Normal Application: Running HTTPS: Working Server health: GOOD Meanwhile: Philippines -> Singapore: Latency: High Packet loss: Present SSH: Unstable User experience: BAD Both observations can be correct. The server itself is healthy. The path to the server is not. A Health Check From One Location Is Not Enough Suppose your monitoring server is also in Singapore. It checks your application: Singapore monitor | +----> Singapore server Latency: 2 ms HTTP: 200 Status: HEALTHY But Philippine users see: Philippines | +----> Singapore server Latency: 177 ms Packet loss Timeouts Your monitoring platform may continue showing green. Your users are still having problems. This is why health measurements from multiple networks and geographic locations can provide a better picture of actual service availability. The PinoyLinux article Health Checks In DNS Steering: From Origin Status To Answer Policy discusses why endpoint health needs to be translated into actual answer policy rather than treated as a simple green or red status. DNS Steering Is Not the Same as Controlling the Connection Another relevant PinoyLinux article is Why DNS Steering Is Not Load Balancing. DNS can influence where a client starts its connection. Once that connection has begun, DNS is no longer carrying the packets. For example: DNS: app.example.com | +----> Singapore IP After resolution: User | +---- Internet route ----> Singapore IP If the international route later becomes congested, authoritative DNS cannot repair that existing TCP session. This matters for: SSH VPN RDP database connections API sessions long-running HTTP connections real-time applications DNS can help future lookups choose a different endpoint. It cannot move every existing connection instantly. BGP Can Route Around a Failure At the network level, BGP allows autonomous systems to advertise routes to one another. When a preferred route disappears, another route may become available or preferred. Simplified: Normal: Philippines ----------> Singapore After a route change: Philippines | +----> Transit Provider A | +----> Regional Hub | +----> Singapore The destination may still be reachable. But that does not guarantee good performance. The new path may: be physically longer cross more networks have less available bandwidth already carry heavy traffic introduce additional latency experience congestion This is one reason a routing incident can result in slow Internet instead of no Internet. Fallback Capacity Matters PinoyLinux also discussed this in Designing Fallback Logic For Reliable DNS Steering. Having a fallback is important. But having a fallback does not automatically mean that the fallback has enough capacity. For example: Preferred: Singapore Fallback: Tokyo If a small amount of traffic fails over, Tokyo may handle it easily. If nearly all regional traffic suddenly moves there: Singapore traffic | +----------> Tokyo | +--> normal Tokyo traffic | +--> rerouted traffic the fallback path itself may become congested. The same principle applies to carrier networks and submarine cables. Redundancy matters. So does spare capacity. Why My SSH Sessions Became Unstable SSH was where I first noticed the incident. The connection did not immediately disappear. It became progressively worse. Commands responded slowly. Typing began to feel delayed. Some sessions eventually froze or disconnected. SSH uses TCP. When packets are lost, TCP retransmits them. As packet loss and delay increase, the connection can behave like this: Normal SSH session | Latency increases | Commands respond slowly | Packet retransmissions | Session appears frozen | Timeout or disconnect The same network conditions can affect: VPNs remote desktop databases APIs VoIP online games video conferencing The application may be perfectly healthy. The path between the two endpoints is the problem. Why Speedtest Can Still Look Perfect This incident is also a useful reminder that a speed test does not measure the entire Internet. Suppose your speed-test server is located inside your ISP network: Home | ISP | Local Speedtest server 500 Mbps 5 ms That tells you your local access connection is performing well. Now consider your Singapore server: Home | ISP | Philippine international gateway | Transit providers | Submarine cable systems | Singapore That path contains far more infrastructure. You can therefore see: Speedtest: 500 Mbps Excellent Singapore SSH: Very slow Disconnecting There is no contradiction. You tested two different network paths. How I Would Troubleshoot This Again If I encounter the same situation again, I would begin with destination comparison. For example: ping singapore-server.example.com ping malaysia-server.example.com ping japan-server.example.com Then examine the route: traceroute singapore-server.example.com On Linux, MTR provides useful ongoing measurements: mtr singapore-server.example.com For a report: mtr -rwzc 100 singapore-server.example.com On Windows: tracert singapore-server.example.com I would also compare the same destination from: another ISP mobile data another office a VPN another cloud server an external monitoring node For example: ISP A -> Singapore: 180 ms ISP B -> Singapore: 55 ms VPN -> Singapore: 60 ms If the destination performs normally through another path, that is strong evidence that the server itself is not the main issue. Cloudflare Also Had Regional Maintenance Scheduled Cloudflare’s public status page is another useful source when investigating regional connectivity: Cloudflare Status Cloudflare had maintenance scheduled for its Hong Kong location on October 2 from 18:00 to 22:00 UTC, with a warning that traffic could be rerouted and users might experience increased latency. That maintenance window occurred later than the initial PH-SG symptoms described in this article, so it should not be treated as the cause of the afternoon slowdown. It is included here because status pages from large network operators are useful when investigating whether a problem is local, regional, or related to wider traffic changes. What the Evidence Shows After comparing the available information, several pieces line up. 1. Firsthand observation Singapore connections became slow and unstable while a Malaysia-hosted server remained usable. 2. Independent PH-SG measurements CableStatus reported approximately 177 ms average PH-SG latency, compared with a recent baseline of around 53 ms, across 28 RIPE Atlas anchors. Source: CableStatus 3. Existing regional subsea maintenance Akamai documented upstream maintenance and congestion involving submarine cable routes around Singapore, Hong Kong, and Japan. Source: Akamai Service Status 4. C2C topology matches the affected corridor C2C’s southern ring connects Hong Kong, the Philippines, and Singapore. Source: Submarine Networks 5. Telstra operates the EAC-C2C network Telstra describes EAC and C2C as wholly owned submarine cable systems serving major intra-Asia routes. Sources: Telstra International Wholesale Telstra Philippines Network Expansion What We Still Cannot Confirm The available evidence does not yet prove that the physical C2C PH-SG cable was cut. That distinction is important. A responsible incident analysis should distinguish: Observed: PH-SG network degradation Measured: Large PH-SG latency increase Reported: Possible C2C PH-SG issue Confirmed: Regional subsea maintenance Not yet confirmed: Physical C2C PH-SG cable break If Telstra or another authoritative carrier later releases a detailed incident report, this article can be updated. The Most Important Clue Was Simple Looking back, the most useful early clue was not a complicated monitoring platform. It was this: Malaysia = normal Singapore = slow That immediately changed the troubleshooting direction. Instead of asking: “Why is my Internet slow?” I started asking: “Why is this particular destination slow?” That is a much more useful question for a system administrator or network engineer. When the Internet behaves strangely, ask: Which destinations are working, and which ones are not? Then ask: Are those destinations using the same network path? Those two questions can quickly help distinguish a local connection problem from a wider routing or international transit issue. Related PinoyLinux Articles The October 2 incident provides a practical example of several concepts already covered in the PinoyLinux DNS steering series. DNS Steering 101: How Authoritative DNS Influences Traffic Direction Explains how authoritative DNS can influence which regional endpoint a requester receives, and why the most suitable endpoint is not necessarily determined by geography alone. Why DNS Steering Is Not Load Balancing Explains why DNS can influence where a connection begins but does not control the network path once the client has connected. Designing Fallback Logic For Reliable DNS Steering Discusses what should happen when a preferred endpoint becomes unavailable or unsuitable. Health Checks In DNS Steering: From Origin Status To Answer Policy Explains why endpoint health needs to influence routing decisions and why a technically running server may still be unsuitable for some users. The Control Plane And Data Plane Of DNS Steering Explains the difference between preparing routing decisions and handling live DNS queries. These articles explain the theory. The October 2 PH-SG incident gives us a real-world example of why those concepts matter. References External Sources CableStatus, Philippines-Singapore Corridor RIPE Atlas-based measurements showing the October 2 PH-SG transit delay advisory, including approximately 177 ms average latency compared with a recent baseline of approximately 53 ms. https://cablestatus.com/?corridor=philippines-singapore Akamai Service Status Akamai incident and maintenance notices covering upstream provider maintenance, increased APAC latency, congestion, and subsea cable maintenance involving Singapore, Hong Kong, and Japan. https://www.akamaistatus.com/ Telstra International Wholesale Network Telstra information about its wholly owned East Asia Crossing and City-to-City submarine cable systems. https://www.telstrainternational.com/en/wholesale/wholesale-updates Telstra Expands Business Offerings in the Philippines Telstra information about its Philippine infrastructure, EAC and C2C landing stations, and the EAC-C2C network. https://www.telstrainternational.com/en/news-research/articles/telstra-expands-business-offerings-in-the-philippines Submarine Networks, C2C Cable System Overview Background, topology, landing stations, and southern-ring information for the C2C submarine cable system. https://www.submarinenetworks.com/en/systems/intra-asia/eac-c2c/c2c-cable-system-overview Cloudflare Status Regional Cloudflare network status and scheduled data-center maintenance information. https://www.cloudflarestatus.com/ PinoyLinux References DNS Steering 101: How Authoritative DNS Influences Traffic Direction https://www.pinoylinux.org/dns-steering-101-how-authoritative-dns-influences-traffic-direction/ Why DNS Steering Is Not Load Balancing https://www.pinoylinux.org/why-dns-steering-is-not-load-balancing/ Designing Fallback Logic For Reliable DNS Steering https://www.pinoylinux.org/designing-fallback-logic-for-reliable-dns-steering/ Health Checks In DNS Steering: From Origin Status To Answer Policy https://www.pinoylinux.org/health-checks-in-dns-steering-from-origin-status-to-answer-policy/ The Control Plane And Data Plane Of DNS Steering https://www.pinoylinux.org/the-control-plane-and-data-plane-of-dns-steering/