1969 ms to Rarotonga: A Week of Congestion on the Manatua Cable

In the early hours of April 11, 2026, a single ICMP reply from Rarotonga took 1968 milliseconds to reach our server in Minsk. At four in the morning the same day, the same reply arrived in 443. By two in the afternoon the network was back to its boring 440 ms baseline and pretending nothing had happened.

This was not a one-off. For the past eight days, five of our measurement probes — in Minsk, Tbilisi, Jerusalem, Sevastopol and Almaty — have been watching the link to the Cook Islands slowly come apart in waves. Our cable monitor, meanwhile, has reported the Manatua cable — the one submarine link that serves all fifteen islands — healthy the entire time. Both of those things are true at once, and this piece is about what that means.

What we measured

Every ninety minutes, each of our probes runs a full traceroute to a single IP address: 202.90.64.1, an edge router inside Telecom Cook Islands at the national network boundary. Over the twenty days before April 3, the baseline round-trip time from Europe or the Caucasus to that address was 430 to 490 milliseconds, stable to within a few milliseconds of jitter. That is the physical reality of routing an IP packet from Minsk to a small Pacific island: Europe → GTT transit across the Atlantic → Los Angeles → Papeete over the Honotua and Manatua cable chain → final leg inside the Cook Islands subscriber network. About 450 ms, round trip, every time.

Then the tail got fat.

The first spike we recorded was on April 3, when one measurement from Tbilisi returned 973 ms instead of the usual 440. A curiosity. Four days later, on April 7, three spikes showed up in the same evening window, one of them hitting 1928 ms from Jerusalem. On April 8, a fourth spike with four timeouts clustered in the late afternoon. Then three calm days — April 9 and 10 looked exactly like baseline. And then April 11 happened.

April 11, hour by hour

Eight days of slowly worsening tail latency compressed into a single day. The worst of it came in two storm windows — one in the middle of the night, one around seven in the morning UTC — and between them, the network looked perfectly fine.

All values are round-trip milliseconds to 202.90.64.1. Values above 800 ms are bolded. Five probes in five different countries, and during the spike windows four of them agreed simultaneously that something was wrong. That rules out a probe-local problem — it is not our Minsk server having a bad morning, it is not a Tbilisi ISP flap. The only way all four Eurasian probes agree at once is if the problem is somewhere past their first common hop, and that common hop is fifteen thousand kilometres and one submarine cable away.

Almaty shows a different pattern — eight timeouts out of fourteen measurements over the day, but no spikes. It has had a low-grade ICMP reachability issue to this particular target for about a week, which we are treating as a separate problem and mentally excluding from the spike analysis.

Same route, different latency

The most useful trace we captured is the one behind that 1969 ms number. Here is what it looks like — and here is what the same probe looked like twenty hours earlier, on a quiet day.

April 10, Minsk → Cook Islands — 466 ms (baseline)

April 11, 02:59 UTC, Minsk → Cook Islands — 1969 ms (spike)

Up to hop 11, the two traces are almost indistinguishable. The path is slightly different — RETN picked a Tallinn ingress on one and a Moscow ingress on the other — but the latency profile is identical: Minsk → Vienna → Los Angeles → Papeete, arriving at 302 milliseconds on a good day and 304 milliseconds on a bad one. If the Manatua transit itself had degraded, or if GTT's Pacific backbone had slowed down, we would see it here. We do not. The cable transit was normal on both days.

The divergence happens after Papeete. On the normal day, three intermediate hops go unresponsive and the target replies at 454 ms — a clean +150 ms for the last segment, which is about what you would expect for the Papeete → Rarotonga fibre link plus a couple of subscriber-network devices. On the bad day, seven intermediate hops go silent and the target replies at 1969 ms — a +1665 ms tail with no physical distance to blame. Same IP, same cable, same transit, same last hop. Different day.

To confirm it is not a Minsk-specific story, here is Jerusalem's spike from April 7, 21:00 UTC, 1928 ms:

Different country of origin, different Eurasian ISP, different transit backbone (Arelion instead of RETN into LA). Same signature. The tail lives somewhere between Papeete and the target endpoint, and it is not made of fibre.

Where do 1650 ms of latency live when they are not made of distance?

The physical distance from Papeete to Rarotonga along the Manatua cable is roughly 1,150 kilometres. Light travels through optical fibre at about 200,000 kilometres per second — two thirds of the speed of light in vacuum, because of the fibre's refractive index. A one-way photon trip over 1,150 km takes 5.75 ms, round-trip 11.5 ms. Add router processing at each end, a bit of queueing on a quiet day, and you get the 150 ms we actually saw on April 10 between Papeete and the target — well within the normal overhead for a small-island network, where the local backbone is built out of commodity switches and the aggregate link to the outside world is not 400 Gbps.

What physics cannot explain is 1665 ms. That is nearly a hundred times the speed-of-light budget for the same path. No fibre anywhere on Earth is slow enough to produce that. It is not distance. It is not a cable cut. It is queueing.

The textbook term is buffer bloat. When a network link saturates — because too much traffic, or too little capacity, or both — packets do not get dropped. They wait in the router's output queue for their turn on the wire. If the queue is large (a megabyte or two, which is perfectly ordinary on commodity hardware) and the link is slow (a few hundred megabits, say), a packet arriving at the back of a full queue can sit there for a second and a half before it is transmitted. It eventually arrives, unharmed. It just took forever. TCP's congestion control was not designed for this: it reacts to drops, not delays, so it never backs off efficiently — and the queue stays full. Latency collapses into a self-reinforcing fog.

On April 11, the queue filled up twice. Once around 01:00 UTC and again around 07:00 UTC. In between the two storms, traffic drained out and our measurements returned to baseline. By 10:00 the tail was gone. If the one-week trend continues — and one isolated spike, followed by a three-spike cluster, followed by a ten-spike wall is a trend — we should expect another window on April 12 and again on April 13.

And meanwhile, the cable is fine

Our cable monitoring system checks Manatua's health independently. Every few hours it pings a landing-point endpoint directly over the cable and records the round-trip latency and a baseline ratio. Here is the same time window, from its point of view:

SELECT * FROM cable_alerts WHERE cable_id='manatua' returned zero rows across the entire window. We did not raise a single warning about the Manatua cable during any of the spike periods. And we were right not to, in the literal sense: the cable was transmitting packets just fine, at almost exactly the same speed as it did yesterday. The problem was elsewhere.

This is the gap worth naming. When cable-level monitoring pings a landing-point endpoint, it exercises the fibre and the edge router on the other side of it. It does not exercise the carrier's backbone, nor the upstream peering arrangement, nor the subscriber access equipment, nor the QoS policy, nor the interface buffer that might currently be four times larger than it should be. In many healthy, well-engineered networks, none of that matters — the submarine cable is the narrowest and most-frequently-failing part of the path, so testing it is a fair proxy for the whole. On a single-cable island, it is not. Everything between Papeete and a user in Rarotonga is one small operator's backhaul, and that backhaul is invisible to a ping test that stops at the cable's edge.

Cook Islands, by the numbers

Fifteen islands, about 17,500 people, most of them on Rarotonga. One submarine cable — Manatua, 3,634 kilometres, in service since 2020, landing on Rarotonga and Aitutaki and then continuing to Niue, Samoa, Bora Bora and Papeete. Before Manatua, the country's international connectivity was O3b satellite, which on a good day meant about 700 ms of latency and on a bad day several multiples of that. One national telco, Telecom Cook Islands, which in practice means the single /24 we keep pointing our traceroutes at. One upstream transit relationship, visible in every one of our traces: AS9471 Onati, out of Papeete.

There is no alternative path. If Manatua goes down, the Cook Islands fall back to satellite. If Telecom Cook Islands mis-provisions a queue on its uplink, a few megabytes of packets build up over the course of an hour and stay there until morning. There is no second supplier to route around, no competing backbone to fail over to. This is what single points of failure look like in practice in 2026.

None of this is a criticism of the operator. Running a national ISP for 17,000 subscribers spread across fifteen islands is a genuine engineering feat, and Manatua was the single most important piece of infrastructure in the Cook Islands' modern history. It is the reality of small-island networking. When things go wrong, they go wrong at the point where there is no redundancy — because that is where there is no redundancy.

What this says about how we monitor cables

We did not catch this week. Our own system, cable health monitoring, had Manatua on a clean scorecard the entire time. It told us the cable was healthy and it was telling us the truth. It simply was not the right question.

The right question, for a single-cable island country, is not "is the cable transmitting packets" but "can a packet reach a subscriber-side endpoint from the outside world and come back in a reasonable amount of time". Those are different measurements with different failure modes, and the gap between them is precisely where an incident like this week's lives. A proper monitoring strategy for the Pacific needs both: cable-level health, which we have, and country-level endpoint health, which we do not have yet at the resolution this kind of pattern requires.

We are going to fix it. Small-island countries with a single commercial telco — Cook Islands, Niue, Tokelau, Tuvalu, Nauru, Kiribati, and a handful of others — deserve their own endpoint-level monitoring track, because they have failure modes their cables cannot express. If we had had it two weeks ago, we would have flagged the April 3 outlier, the April 7 cluster and the April 8 window as a building trend, and we would have walked into April 11 expecting it instead of discovering it in the morning report.

What is actually causing this?

Honestly — we do not know.

What we can see from outside: the Manatua cable is fine, the GTT transit from Europe to Papeete is fine, the problem is somewhere past hop 11 inside the Onati and Telecom Cook Islands network, and it manifests as a queueing delay pattern consistent with buffer bloat on a saturated link. What we cannot see: whether that saturation is a capacity-planning issue (subscribers finally outgrew the uplink), a partial fibre degradation on the Pacific segment that halved effective bandwidth, a routing change that shifted more traffic through one pipe, a misconfigured interface buffer, a peering dispute, or something else entirely. Those are the questions you can only answer from inside the operator's network, and we are not inside it.

What we can say with confidence is that it is getting worse. One spike on April 3. Three on April 7. Ten on April 11. Each wave larger than the last; each big spike closer to the 2,000 ms ceiling where TCP itself starts to fall apart. If the trend holds — and eight days of data, four spike windows, and an ordered sequence is a trend — we will be writing about April 13 or April 14 next, not just April 11.

Try it yourself

We publish live measurements to this destination on the route monitor — it updates as new traceroutes come in, and if the pattern we described here continues, the chart will show it. You can also read the baseline story that set up these measurements: how a clean round trip to the Cook Islands gets to 462 ms in the first place. And the cable itself has its own page: Manatua, the 3,634 km Pacific backbone that has, since 2020, been the only fibre link between the Cook Islands and the rest of the world.

We will follow up with what April 12 and April 13 bring.