Cable damage disrupted O2 and Guyana; J:COM reports DNS overload

Cable damage links two otherwise separate disruptions in the Czech Republic and Guyana, while J:COM attributes its Japanese service failure to overloaded DNS servers. Public statements also add context to Cuba’s power-related connectivity losses and Digicel Haiti’s interrupted international link. Archived measurements provide a second view of disruption in Iraq and Guyana, but cannot establish causes or individual operators’ impact. Across seven reported outages and 24 automated anomalies, restoration times and measurement windows often differ. Several remaining signals have no verified explanation. [4] [5] [6] [7] [8] [1] [2] [3]

O2 identifies construction damage behind Monday’s disruption

Archived Cloudflare Radar measurements place O2 Czech Republic’s September 21 disruption within a one-hour-and-45-minute window. Its automated anomaly covers a shorter interval inside that record. Radar labels the cause a technical problem, while its description reports problems with internet connectivity and the customer application. [1]

O2 supplied a more specific explanation on September 22: construction work had severed an important CETIN fibre connection, affecting some customers’ fixed and mobile internet during Monday morning. The company also announced a shopping voucher worth 200 Czech crowns. This is the operator’s account of the incident. O2 statement [4]

The operator statement supports a physical infrastructure explanation beyond Radar’s broad technical classification. It does not establish how many customers lost access throughout the measurement window, or reconcile the shorter automated interval. Which services recovered first, and whether some customers remained affected longer, remain unresolved. [1] [4]

What remains unresolved

• What were the service-specific restoration times and geographic limits?
• Radar’s outage window is 06:30 to 08:15 UTC; its anomaly window is 06:45 to 08:00 UTC on September 21.
• O2 describes September 21 'morning hours' without precise endpoints. No operator source window is assigned.
• The network identifier is AS5610. Its registration country is not a measured impact boundary.
• Historical record details come from the supplied archive; the consulted live Radar page did not expose those rows in its text rendering.

Guyana’s cable cut brought partial recovery before full capacity

Radar’s archived One Communications outage spans 11 hours and 15 minutes across September 23 and 24. A country-level automated anomaly covers a shorter period. The archive also contains overlapping IODA active-probing evidence, providing a second monitor’s indication of connectivity loss in Guyana without identifying every affected operator. [1] [2]

Demerara Waves reported from a company official that a contractor cut a fibre cable while working on a drain near Carifesta Avenue. By Wednesday evening, service had returned at reduced capacity, with slow speeds and buffering still possible. The report also identified disruption to MMG and top-up services at several locations. Original reporting [5]

The company account published by Village Voice dates the damage to approximately 3:16 PM on September 23, with reduced-capacity service about an hour later. News Source Guyana’s September 24 report places temporary full restoration at 12:05 that morning. Neither consulted account specifies the timezone for those event times, so they remain in the sources’ wording. Company account, restoration report [6] [7]

The evidence supports a cable-cut explanation and a staged recovery. It does not support treating Radar’s entire window as complete loss of service for every subscriber. The company said the repaired connection remained temporary; whether permanent repairs were completed, and how capacity varied during recovery, remain open questions. [1] [6] [7]

What remains unresolved

• When was the permanent repair completed, and what capacity was available during each recovery stage?
• Radar names AS19863, Guyana Telephone & Telegraph Co., associated in the record with One Communications.
• The company account gives approximately '3:16 PM on September 23, 2026'; the September 24 report gives '12:05 this morning'. Timezones are unspecified, so neither becomes an ISO source window.
• Demerara Waves initially reported an expected restoration by '9 p.m. Wednesday', not a confirmed completion. Its image metadata says October 23, while the article date and body concern September 23.
• News Source Guyana describes service being down for more than two hours while also relaying reduced-capacity restoration approximately one hour after the incident. Those descriptions are not reconciled.
• Village Voice and News Source Guyana relay the same company explanation and are not two independent confirmations of the cause.
• IODA’s archived country-level signal supports disruption in Guyana, not independently measured impact on AS19863. Exact IODA alert endpoints were not supplied.

J:COM attributes service failure to overloaded DNS servers

Archived Radar records show an 11-hour disruption on J:COM’s network on September 23, alongside an automated anomaly lasting five hours and 15 minutes. Radar classifies the incident as a network problem. The different endpoints describe different records and should not be treated as competing proof of universal restoration. [1]

J:COM’s September 24 update says heavy external access overloaded DNS servers. It lists internet access, online television functions, mobile internet and some login services among the affected products, while reporting no confirmed impact on television broadcasts. Its stated September 23 window is '8:55' to 'around 18:00', with final confirmation at '20:00'; the page does not explicitly identify a timezone. J:COM update [8]

The operator distinguishes repair completion from final service confirmation, helping explain why a traffic endpoint need not equal a customer’s recovery time. Its explanation establishes an operator-reported DNS overload, but leaves the nature and source of the external traffic unresolved. The consulted statement does not establish an attacker or motive. [1] [8]

What remains unresolved

• What generated the external traffic, and what technical evidence supports that explanation?
• J:COM states September 23 '8:55' to 'around 18:00', repair completion around '18:00', and final service confirmation at '20:00'. No timezone is explicit, so operator source windows are omitted.
• The September 24 update narrows the affected J:COM NET area to exclude Hokkaido and Kyushu, while also identifying some partner cable operators. This is not a nationwide loss of Japanese internet access.
• Radar’s network identifier is AS9824. The archive contains no independent network-level measurement check.
• The linked J:COM X post could not be fetched; the company’s public news release supplies the operator explanation.

Cuba’s power failure affected connectivity, but the clocks do not align

Radar’s archived Cuba record begins on September 18 and ends three hours into the observation week on September 21. Its power-outage classification accompanies a 75-hour record, not evidence of uninterrupted nationwide internet loss. The archived IODA check contains no alerts for that interval, which does not disprove the disruption. [1] [2]

ETECSA’s September 24 statement says a recent national electricity-system collapse interrupted more than 80 percent of radio-base sites and nearly 70 percent of telecommunications cabinets, with internet traffic losses reaching 58 percent against comparable periods. The operator describes both lost coverage and congestion where surviving sites faced concentrated demand. These are company-reported infrastructure and traffic figures. ETECSA statement [9]

CiberCuba’s dated reconstruction places the September 18 grid collapse at '13:57', in its Cuba-time presentation, later than Radar’s recorded start. That mismatch prevents a precise alignment of the two events. The evidence supports electricity-related connectivity problems, while leaving the onset, changing severity and final restoration of this particular internet disruption unresolved. Dated reconstruction [1] [10] [9]

What remains unresolved

• Why does Radar’s record begin before the reported September 18 afternoon grid collapse?
• Only 2026-09-21T00:00:00.000Z to 2026-09-21T03:00:00.000Z overlaps the observation week; the full record is preserved below.
• CiberCuba gives '13:57' on September 18 and labels its presentation 'Hora de Cuba'. No numeric UTC offset is supplied, so no converted source window is assigned.
• ETECSA’s September 24 statement says the collapse occurred 'a few days ago' rather than providing precise event endpoints.
• ETECSA’s percentages describe sites, cabinets and traffic, not affected-person counts.
• Radar names AS27725. Its nationwide classification does not mean every connection was continuously unavailable.

Digicel restoration account identifies an interrupted international link

Radar records a Digicel Haiti disruption spanning 16 hours and 45 minutes across September 23 and 24. Its overlapping anomaly starts later and ends earlier. A separate September 21 anomaly remains distinct. Radar’s description tentatively associates the longer disruption with routing changes, while leaving the cause field unknown. [1]

Le Médiateur reported on September 24 that Digicel chief executive Jean-Philippe Brun announced restoration of an international link affected along National Road 1. The article quotes his public statement thanking customers and promising compensation. It supplies an operator account of the affected infrastructure, but no precise restoration time or explanation of what damaged or interrupted the link. Restoration report [11]

The link-restoration account adds context to Radar’s traffic decline without proving that routing changes were the underlying cause. Nor does it connect the September 21 anomaly to the later incident. The unresolved questions are what interrupted the international link and whether the two observed episodes shared any infrastructure or failure mechanism. [1] [11]

What remains unresolved

• What interrupted the international link, and was the September 21 anomaly related?
• The reported outage window is 21:30 September 23 to 14:15 September 24 UTC; the overlapping anomaly is 21:45 to 14:00 UTC.
• The operator statement was consulted through Le Médiateur’s quotations, not directly on the executive’s X account. It represents one operator statement lineage.
• The restoration report is dated September 24 but gives no precise event time, so it supplies no source window.
• Radar identifies AS27653. The archive lacks an independent network-level check; missing country metadata does not mean such a check is inherently impossible.

Iraq disruption has a second measurement signal; the specific order remains unverified

Radar’s archived Iraq record covers 15 minutes on September 26 and names five networks. IODA’s active probing and network-telescope signals also registered disruption during that interval, according to the archive. These are two measurement methods within a second monitoring project, supporting connectivity loss without establishing each named network’s customer impact. [1] [2] [3]

Radar labels the event government-directed and describes an examination shutdown. An operator notice from LightNode documents government-mandated interruptions reported by Hulum, Earthlink and Zain for an earlier examination schedule ending September 12. That notice establishes relevant prior practice, but does not cover September 26 or independently verify Radar’s explanation for this event. LightNode notice [1] [12]

The measured disruption is better supported than the specific explanation. No directly consulted government order establishes the September 26 instruction or its intended duration. Five associated network anomalies have identical start and end timestamps; those records cannot establish zero-minute outages, immediate recovery or a common duration across all five providers. [1] [2]

What remains unresolved

• Which dated government or operator instruction governed September 26, and what duration did it specify?
• Radar names AS199739 Earthlink-DMCC-IQ, AS203214 HulumTele, AS51684 ASIACELL, AS58322 halasat and AS59588 ZAINAS-IQ.
• AS199739’s UAE registration is not evidence of an outage in the United Arab Emirates.
• The five network anomalies have identical endpoints at 2026-09-26T03:30:00.000Z. Their actual disruption durations are unresolved.
• IODA’s country-level active-probing and Merit telescope signals do not establish operator-level scope, government direction, actor or motive. Exact IODA alert endpoints were not supplied.
• LightNode’s earlier schedule covers August 26 through September 12 and cannot be substituted for a September 26 order.
• Radar’s description says the special examination round runs September 26 through October 10; that schedule was not independently established from a government source.

Fanap outage remains unexplained

Radar describes a complete loss of the traffic it observed from Fanap Telecom late on September 27, with a record extending 45 minutes beyond the observation week. An earlier FDI anomaly occurred on September 23. A separate Mobinnet record on September 27 has identical endpoints and therefore supplies no usable outage duration. [1]

Targeted searches and consultation of Fanap’s public website did not locate an event-specific operator explanation. The cause therefore remains unverified, and the three episodes cannot be joined into a national outage or a single causal story. The central unanswered question is whether the two Fanap signals reflect the same recurring fault. [1] [13]

What remains unresolved

• Did the September 23 and September 27 Fanap episodes share a cause?
• FDI / Fanap is AS206065; Mobinnet is AS50810. Registration in Iran does not establish national impact.
• The September 27 outage and matching anomaly extend to 2026-09-28T00:45:00.000Z, beyond the observation week’s 2026-09-28T00:00:00.000Z cutoff.
• Mobinnet’s identical endpoints are not evidence of a zero-minute outage.
• The linked Cloudflare X post could not be fetched. The complete-traffic-loss description is attributed to the supplied Radar archive, not independently reproduced measurements.
• No reviewed evidence establishes a relationship between Mobinnet and Fanap or supports a cyberattack or censorship explanation.

Four Republic of the Congo signals lack an event-specific explanation

Radar’s archive contains four country-level traffic anomalies for the Republic of the Congo on September 21, 22, 24 and 26. Each recorded interval lasts between 90 and 105 minutes. None names an affected operator or gives a cause, and the records do not establish continuous nationwide loss of access. [1]

Later context comes from Congo Telecom’s September 28 statement, outside the observation week: it says rerouting maintained its traffic after a WACS cable fault detected September 2. It does not connect that fault to these four anomalies. Whether any particular operator or shared route explains the repeated country signals remains unresolved. Dated operator statement [14] [1]

What remains unresolved

• Which networks contributed to each country-level anomaly, and did they share a cause?
• CG is the Republic of the Congo, not the Democratic Republic of the Congo, whose country code is CD.
• Congo Telecom’s statement is dated September 28, after the observation week. Its publication clock reads '10:19:35' without a timezone.
• The operator statement describes a September 2 cable fault and a repair vessel arriving September 21. These date-only claims are context, not measured outage windows.
• The statement says traffic was maintained on Congo Telecom’s network; that claim neither explains nor disproves country-level signals involving potentially different networks.
• The operator article was available through the search index; direct page retrieval failed.

Three Gabon traffic anomalies remain unexplained

Radar’s archived measurements flag two Gabon traffic anomalies on September 23 and another on September 26, each covering 75 minutes. These are country-level automated records, with no named network and no cause attached. They establish recurring unusual traffic in Radar’s view, but do not establish a countrywide service interruption. [1]

The public-source review did not locate an operator statement or event-specific reporting that explains these intervals. Their repetition is a reason for further investigation, not evidence of one shared fault or deliberate restriction. Which providers contributed to the signals, and whether customers experienced loss of access, remain the practical unanswered questions. [1]

What remains unresolved

• Which providers drove the signals, and was there customer-visible loss of access?
• No event-specific external explanation was located for the September 23 and 26 intervals.
• Radar’s VERIFIED label is provider metadata, not independent verification of cause or nationwide impact.
• No shared cause with the Republic of the Congo anomalies has been established.

Israel-registered and Taiwan-registered network signals remain unconfirmed leads

Radar flags overlapping September 21 anomalies on PARTNER-AS and HOTNET-IL, lasting 13 and 12 hours respectively. A separate TFN-TW anomaly on September 25 spans nine hours and 30 minutes. Israel and Taiwan are the networks’ registration locations in these records, rather than independently measured boundaries of customer impact. [1]

Targeted searches did not locate event-specific operator explanations for these three signals. They are grouped here as unexplained leads, with no proposed connection between Taiwan and the two Israel-registered networks. Even the overlapping Israeli intervals leave a basic question unanswered: did customers lose connectivity, or did traffic change for another reason? [1]

What remains unresolved

• Did each signal reflect customer connectivity loss, altered usage or a change in observed traffic paths?
• The networks are AS12400 PARTNER-AS, AS12849 HOTNET-IL and AS9924 TFN-TW.
• The archive labels all three TP; no independent cause or customer-impact verification is supplied.
• The overlap between PARTNER-AS and HOTNET-IL does not establish a common cause.
• No reviewed source connects the TFN-TW anomaly to a particular cable fault or other infrastructure event.

Sources and evidence

1. Cloudflare: Cloudflare Radar Outage Center. Supports: Evidence origin for all seven outage records and 24 anomalies supplied in the archive generated September 28. The consulted page identifies automated anomalies and UTC timestamps; historical event details were supplied by the archive, not reproduced from the live text rendering. [1]

2. Georgia Tech Internet Intelligence Lab: IODA internet connectivity monitoring. Supports: Origin of archived country-level checks: active probing and Merit telescope signals for Iraq, active probing for Guyana, and no archived alerts for Cuba. The public interface was consulted but its text rendering did not expose historical alert endpoints. [2]

3. Georgia Tech Internet Intelligence Lab: IODA data sources and detection glossary. Supports: Explains active probing, BGP visibility, Merit network telescope data and aggregation by country, region and network. Supports distinctions between measurement methods and their geographic scope. [3]

4. O2 Czech Republic: O2 explains September 21 service disruption (2026-09-22). Supports: Operator attributes some fixed and mobile internet unavailability to construction damage to a CETIN fibre connection and announces a 200-crown voucher. [4]

5. Demerara Waves: One Communications services return at reduced capacity (2026-09-23). Supports: Denis Chabrol’s original reporting quotes a company official on a cut cable, reduced-capacity recovery, an expected repair deadline, and disruption to MMG and top-up services. [5]

6. Village Voice News: Published One Communications account of fibre damage (2026-09-25). Supports: Company account places cable damage at approximately 3:16 PM September 23, describes reduced-capacity recovery and a temporary repair. Event clock times have no explicit timezone. [6]

7. News Source Guyana: One Communications reports temporary full restoration (2026-09-24). Supports: Relays the company’s construction-damage explanation and temporary full restoration at 12:05 that morning. Shares the company-statement lineage with the Village Voice account. [7]

8. JCOM: J:COM September 24 cause and restoration update (2026-09-24). Supports: Operator update attributes failure to DNS-server load from heavy external access, identifies affected services and areas, and distinguishes repair completion from final confirmation. Page also carries an initial September 23 date. [8]

9. ETECSA: ETECSA explains power-related telecommunications disruption (2026-09-24). Supports: Operator reports infrastructure unavailability, internet traffic losses and congestion following a recent national electricity-system collapse. Does not provide precise outage endpoints. [9]

10. CiberCuba: September 18 Cuba electricity-system timeline (2026-09-18). Supports: Dated reconstruction gives a 13:57 grid-collapse time and distinguishes partial recovery from national reconnection. Page states an update on September 24 and labels its presentation Cuba time. [10]

11. Le Médiateur: Digicel chief executive announces international-link restoration (2026-09-24). Supports: Quotes Jean-Philippe Brun’s statement about restoring an international link affected along National Road 1 and planned customer compensation. No precise incident clock or underlying cause is provided. [11]

12. LightNode: LightNode notice on an earlier Iraq examination shutdown schedule. Supports: Search-indexed operator notice relays Hulum, Earthlink and Zain notifications for examination interruptions ending September 12. It does not cover September 26; direct text rendering omitted the notice body. [12]

13. Fanap Telecom: Fanap Telecom public website. Supports: Operator website consulted during event-specific research. No explanation for the archived September 23 or September 27 disruption was located; the site is not independent confirmation of either incident. [13]

14. Congo Telecom: Congo Telecom September 28 WACS repair statement (2026-09-28). Supports: Later context outside the observation week: operator says rerouting maintained traffic after a September 2 WACS fault and describes a repair vessel arriving September 21. Consulted through indexed content; does not explain the four country anomalies. [14]

Method and reporting window

This issue covers records overlapping 2026-09-21T00:00:00.000Z through 2026-09-28T00:00:00.000Z, with the end excluded. The evidence snapshot was assembled at 2026-09-28T13:00:03.275Z. Continuing events can appear in adjacent issues.

Signal Atlas compares public measurements; it does not operate its own probes. IODA country-level connectivity checks use a three-hour margin around the relevant record window. Multiple IODA sensors are one organisation. News reporting can supply context without becoming another independent internet measurement. Traffic anomalies can overlap outage reports and must not be added as separate confirmed incidents.