The week’s strongest story is Cuba, where Cloudflare Radar marked an open nationwide internet outage from 2026-09-18 and the frozen evidence packet says IODA also saw a disruption through Google Transparency Report data. Public reporting and ETECSA’s own notice point to power instability affecting telecommunications, but the internet measurements do not by themselves prove the full geographic boundary or duration. In Portugal, two short MEO disruptions matched IODA active probing and were later described by MEO as DDoS incidents. Congo, Gabon and SKYBB-AS-AP in the Philippines remain cause-unconfirmed Radar anomaly leads. [1] [2] [3] [4] [5]
Cuba remains open in the archive. Radar listed a Cuba outage beginning 2026-09-18T00:00:00Z with no closed end in the packet. The packet says IODA also saw a disruption via Google Transparency Report data. Treat the open record as unresolved, not as proof of uninterrupted nationwide loss through publication time. [1] [2] [3]
MEO gave a post-incident explanation. MEO said its September 14 disruptions were caused by a targeted DDoS against international network infrastructure, and said observed BGP instability was a consequence rather than the cause. Radar had classified two MEO events as cyberattack, while IODA active probing supplied a second measurement signal. [1] [4] [5] [2]
Several country anomaly leads stayed unexplained. Repeated Radar anomalies for the Republic of the Congo, Gabon and one SKYBB-AS-AP signal in the Philippines had no verified operator or government explanation in the consulted public sources. They should stay as measurement leads, not outage narratives with inferred causes. [1]
Cuba blackout coincided with an open measured internet outage
Cloudflare Radar recorded a Cuba nationwide internet outage beginning at 2026-09-18T00:00:00Z and still open in the archived packet. The packet names AS27725 Empresa de Telecomunicaciones de Cuba S.A and says IODA independently observed a disruption in Cuba through Google Transparency Report data. Those measurements support disrupted connectivity, but not the precise population affected or a continuous outage through the open record. [1] [2] [3]
The national power context is unusually strong here. On September 18, 14ymedio reported that Cuba’s Ministry of Energy and Mines announced a total disconnection of the electrical system, while the Unión Eléctrica described transmission-line trips between Matanzas, Cienfuegos and Santa Clara before the full system disconnection. It also noted unstable weather in the area and an uncertain restoration timeline. [6]
ETECSA had warned one day earlier that the energy situation and difficulties with generators at technology sites were increasing impacts on several telecommunications services, which would be restored as sites received power. That is relevant because it is an operator statement tying telecommunications degradation to energy supply, although it predates the Radar outage start and does not define the internet outage window. [7]
Assessment: power failure is a plausible explanation for the measured internet disruption, but the archive should keep the layers separate. Radar classified the internet outage as power-related; Cuban electrical and telecom sources describe an electricity crisis affecting services; IODA and Google traffic are measurement signals. The unresolved question is how much of AS27725’s access network was offline at each stage of restoration. [1] [2] [3] [6] [7]
What remains unresolved
- Radar outage: outage:1670 starts 2026-09-18T00:00:00.000Z and has no closed end in the packet; do not treat it as proof of uninterrupted nationwide loss through 2026-09-21T16:38:47Z.
- IODA corroboration in the packet is country-level CU via google-transparency-report; it does not establish operator-level impact, cause, actor or motive.
- Cloudflare also logged Cuba anomaly records anomaly:da774583-c7a3-49c8-8762-edf5bb1add70, anomaly:93a11ea5-464c-4009-9823-b211a778f025 and AS27725 anomaly:03f93c1b-d2b7-496b-9d7d-b2bd2a12cef8; these are not separate proven outages.
- ETECSA’s September 17 Telegram notice gives a date but not a precise timezone in the consulted mirror; it is context, not a measured internet window.
MEO reported DDoS after two measured Portugal disruptions
Cloudflare Radar recorded two short Portugal network outages on MEO: one from 2026-09-13T23:45:00Z to 2026-09-14T01:30:00Z and another from 2026-09-14T16:30:00Z to 2026-09-14T17:15:00Z. The packet says IODA active probing also observed disruption in Portugal during both windows, giving a second measurement view without proving cause. [1] [2]
MEO later published a September 15 statement saying its engineering, operations and cybersecurity teams concluded that incidents on its international network infrastructure were caused by a targeted distributed denial-of-service attack. MEO listed incident periods as 00h45-02h55, 17h30-19h30 and 22h45-01h05, said the service was stabilized, and said there was no intrusion or customer-data compromise. [4]
The MEO statement directly addressed a competing technical interpretation: it said BGP routing instability was a consequence of attack-driven degradation and operational response, not the origin of the incident. Observador’s September 14 report had already carried MEO’s statement that a mass attack caused congestion and degradation of the international network, with DownDetector complaints peaking at more than 7,200 at 18:19. [4] [5]
Assessment: the MEO statement is the strongest available operator explanation, but Signal Atlas should present DDoS as MEO’s reported cause rather than independently established fact. The open question is whether outside routing or traffic data can verify the three local-time windows MEO published, especially the later 22h45-01h05 period that falls outside the two Radar outage records in the packet. [1] [4] [5] [2]
What remains unresolved
- MEO’s statement lists periods as 00h45-02h55, 17h30-19h30 and 22h45-01h05 without an explicit timezone in the consulted page; no sourceWindows entry is created for those operator periods.
- Radar outage:1668 names AS3243 MEO-RESIDENCIAL and AS42863 MEO-MOVEL from 2026-09-13T23:45:00.000Z to 2026-09-14T01:30:00.000Z; IODA corroboration is country-level PT active probing in the packet.
- Radar outage:1669 names AS3243 MEO-RESIDENCIAL and AS42863 MEO-MOVEL from 2026-09-14T16:30:00.000Z to 2026-09-14T17:15:00.000Z; IODA corroboration is country-level PT active probing in the packet.
- Radar anomaly records anomaly:3e5dda43-ab4d-4b7b-9fbe-107780827530 and anomaly:1eae4a4d-4363-49ce-b72e-005f3f31ab5f are aligned with the two MEO outage windows but remain automated traffic records.
Republic of the Congo produced repeated unexplained Radar anomalies
Cloudflare Radar logged eight automated traffic anomalies for the Republic of the Congo during the week: two on September 14, one on September 16, one on September 17, two on September 18, one on September 19 and one on September 20. The records are country references using HTTP and NET signals. They are not operator statements and do not identify a named network. [1]
The consulted public sources did not provide a matching operator notice, government outage statement or original reporting explanation for these Congo windows. That makes this a recurring measurement lead rather than a publishable cause story. It is also important to keep the country code straight: these records are CG, the Republic of the Congo, not CD, the Democratic Republic of the Congo. [1]
Assessment: repeated signals make the Congo cluster worth watching, but the archive does not establish whether users experienced a broad outage, a smaller traffic shift, routing instability, power-related service loss or measurement artifact. The unresolved question is whether any Congolese access provider or regional exchange saw operational incidents matching the Radar windows. [1]
What remains unresolved
- No consulted public operator, government or original reporting source explained the CG anomaly cluster.
- Radar country-level anomalies do not prove operator-level impact, nationwide impact, cyberattack, censorship, actor or motive.
- The Republic of the Congo country code is CG; do not merge these records with Democratic Republic of the Congo, CD.
Gabon had short Radar anomaly records without a sourced explanation
Cloudflare Radar logged Gabon country-level traffic anomalies on September 16 and September 19. The September 16 entries were separated into a 45-minute midday record and a longer evening record running into September 17. A September 19 record has identical start and end timestamps in the archive, which should not be read as a zero-minute outage. [1]
No consulted public operator notice, regulator statement or original news report established a cause for the Gabon signals. Without that outside context, the responsible reading is narrow: Radar saw automated HTTP and NET anomalies for Gabon, but the record does not identify an affected ASN or explain whether end users lost access. [1]
Assessment: Gabon belongs in the report as an unexplained lead, not as a developed outage claim. The unresolved question is whether the September 16 evening signal reflected a real service interruption, a measurement baseline shift or a smaller network event that did not produce public reporting. [1]
What remains unresolved
- No consulted public source explained the Gabon anomaly records.
- The anomaly:d5458171-5774-4c79-b4a4-9dc09b68ad47 record has matching start and end timestamps; this should not be interpreted as a confirmed zero-minute outage.
- Radar country-level anomalies do not identify a provider, cause, actor or motive.
SKYBB-AS-AP anomaly in the Philippines stayed isolated
Cloudflare Radar logged one AS-level traffic anomaly for SKYBB-AS-AP, AS23944, registered to the Philippines, from 2026-09-18T01:30:00Z to 2026-09-18T02:45:00Z. The archive labels the location as ASN registration country, which is not the same thing as a measured geographic outage boundary. [1]
The consulted public sources did not produce a matching operator statement, regulator notice or original reporting account for this SKYBB-AS-AP window. With no second measurement lineage in the packet and no external explanation, the record remains a single-source traffic anomaly. [1]
Assessment: the Philippine record is useful as a lead for network-watch readers, but it should not be promoted into a broader Philippines outage. The unresolved question is whether AS23944 saw a localized access issue, upstream congestion, maintenance, or a measurement-only deviation during the 75-minute Radar window. [1]
What remains unresolved
- No consulted public source explained the AS23944 anomaly.
- ASN registration country is not a measured outage location; the packet does not establish a Philippines-wide disruption.
- There is no IODA corroboration listed for this anomaly in the packet.
Sources and evidence
1. Cloudflare Radar: Cloudflare Radar Outage Center. Supports: Radar origin for outage and anomaly records; page states outage and anomaly timestamps are in UTC. [1]
2. CAIDA / Georgia Tech Internet Intelligence Lab: IODA Internet Outage Detection and Analysis project overview. Supports: Explains IODA’s measurement sources, including BGP, Internet Background Radiation and active probing, and its goal of identifying macroscopic outages affecting an AS or large fraction of a country. [2]
3. Google Transparency Report: Traffic and disruptions to Google. Supports: Explains Google product traffic data used as a visibility source for regional disruptions. [3]
4. MEO Fórum: Comunicado: MEO esclarece ataque DDoS à sua rede internacional (2026-09-15). Supports: Primary MEO statement saying September 14 incidents were caused by DDoS, listing incident periods, saying BGP instability was a consequence, and denying intrusion or data compromise. [4]
5. Observador: Meo foi alvo de ataque em massa que afetou serviços de telecomunicações (2026-09-14T22:01:00). Supports: Original reporting carrying MEO’s September 14 statement and noting DownDetector complaint volume during the Portugal service disruption. [5]
6. 14ymedio: Nuevo apagón total en Cuba por el colapso del sistema eléctrico (2026-09-18T15:31:00). Supports: Reports Cuban Ministry of Energy and Mines and UNE statements on September 18 total electrical system disconnection, transmission-line trips, unstable weather and recovery uncertainty. [6]
7. ETECSA_Cuba via public Telegram mirror: ETECSA public Telegram notice on energy-related telecom impacts (2026-09-17). Supports: ETECSA statement that the energy situation and generator difficulties at technology sites were increasing impacts on telecommunications services, with restoration as power returned. [7]
Method and reporting window
This issue covers records overlapping 2026-09-14T00:00:00.000Z through 2026-09-21T00:00:00.000Z, with the end excluded. The evidence snapshot was assembled at 2026-09-21T13:00:28.313Z. 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.