Digicel Haiti disruption spans more than a day; Iraq outage timings diverge

Archived measurements show a Digicel Haiti disruption spanning more than a day, alongside two Iraqi disruptions that Cloudflare classifies as exam shutdowns. Haitian reporting describes fiber problems and interrupted daily activities. Iraq’s October 4 records disagree substantially on duration. A second monitor supports connectivity loss in Iraq and Eswatini, without establishing the causes. Research also found relevant Ukrainian network observations and a Taiwan maintenance notice. Iran’s newer signals and several other anomalies remain unexplained. Open records and identical start and end timestamps do not establish continuous outages or their duration. [1] [5] [6] [9] [2] [3] [4]

Digicel disruption interrupts work and communications in Haiti

Archived Cloudflare measurements record a Digicel Haiti disruption from October 3 into October 4, spanning 28 hours 45 minutes. The provider describes a complete disappearance of the network’s Internet traffic and classifies the cause as cable damage. That describes Cloudflare’s observation of this network; the archive contains no independent measurement check establishing the same impact across Digicel’s services. [1]

Reporting supplies a more specific explanation. On October 3, Le Facteur Haïti attributed the disruption to problems with two international fiber connections on Route Nationale 1, citing Digicel chief executive Jean-Philippe Brun. It said technicians were working to restore service. This is an operator explanation conveyed through a news report; the original statement was not independently retrieved. Le Facteur Haïti. [5]

On October 4, Vant Bèf Info described customers approaching 24 hours without Internet, including workers unable to send files, merchants struggling to contact customers and students having trouble accessing coursework. Its account supports tangible disruption but supplies no precise restoration time. The reported fiber problems fit Cloudflare’s classification, while the extent of damage and the return of individual services remain unresolved. Vant Bèf Info. [6] [5] [1]

What remains unresolved

• When did Internet access return for customers in each affected area, and did voice or messaging services follow the same timeline?
• Cloudflare’s network is AS27653. Its traffic observation does not establish that every Digicel service or every Haitian Internet connection failed.
• The October 3 report says the disruption was observed in the morning; the October 4 report says nearly 24 hours. Neither provides a timezone-qualified incident window, so neither receives a sourceWindows entry.
• The archive’s absence of an independent check reflects its coverage, not proof that independent verification is impossible.
• The original Digicel statement and a detailed repair or restoration notice were not retrieved.

Iraq’s repeated disruptions have conflicting recovery windows

Archived measurements show overlapping Iraqi country and network disruptions on September 28 and October 4. Cloudflare names Earthlink, HulumTele, Asiacell, Halasat and Zain. IODA, a second monitoring system, detected country-level connectivity loss during both events. Its September 28 check includes active probing and telescope signals; October 4 includes active probing. These observations support disruption without independently establishing each operator’s customer impact. [1] [2] [4]

Cloudflare labels both events government-directed exam shutdowns, identifying a special examination round in its September annotation. Al Rabiaa reported on September 28 that the Education Ministry had rescheduled special-round examinations because of the September 30 through October 3 holiday. That establishes relevant examination context, but the report contains no shutdown order or confirmation of these specific Internet interruptions. Al Rabiaa. [1] [7]

The duration evidence differs materially. Radar’s September event spans 15 minutes, while Telecom Observer reports roughly 40 minutes. For October 4, Radar’s curated record spans nine hours, although every named network anomaly ends within the first hour. Telecom Observer again describes about 40 minutes. Its summaries do not expose enough sourcing to establish an additional independent measurement lineage. September report, October report. [1] [8] [9]

The repeated timing and Cloudflare’s classification make an exam-related interruption a supported provider explanation. They do not resolve the long October country window or establish a nine-hour shutdown across all five networks. A dated government directive or operator restoration account is still needed to explain what continued after the network anomalies ended and whether the same mechanism caused both events. [1] [2] [7] [9]

What remains unresolved

• What explains the October 4 country signal continuing until 11:45 UTC when all five network anomalies ended at 03:45 UTC?
• No contemporaneous government directive or operator notice confirming the two shutdown orders was retrieved.
• Named networks: AS199739, AS203214, AS51684, AS58322 and AS59588. AS199739’s UAE registration does not establish an outage in the UAE.
• The archived IODA results indicate overlap with the Radar windows; they do not provide independently established start and end times for each operator.
• IODA’s active probing and Merit telescope are distinct signals within the same monitoring system, not two additional news organizations.
• Al Rabiaa’s page displays September 28, 2026 and 06:00 without an established timezone. Its examination dates are context, not measured outage endpoints.
• Cloudflare’s special-round date annotation and the subsequent examination rescheduling should not be treated as an independently verified daily shutdown timetable.

Eswatini disruption is measured; the power explanation needs its original notice

Cloudflare’s archived record describes a 75-minute disruption in Eswatini on September 29, with Manzini most affected. IODA’s active probes also detected country-level connectivity loss during that period. Cloudflare classifies the event as nationwide and links it to planned electricity interruptions, but names no affected network. Its geographic classification does not demonstrate that everyone in the country lost access. [1] [3]

The electricity company’s public outage page explains its notification process but offered no matching September 29 notice in the material retrieved. Telecom Observer reports a broader Internet disruption window, approximately 10:50 to 12:30 UTC, and leaves the cause unexplained. That timing is preserved alongside Radar’s shorter window; the report does not independently verify the electricity explanation. EEC outage notices, Telecom Observer. [10] [11] [1]

A further country anomaly appears early on September 30 and lasts 90 minutes in the archive. No retrieved operator statement links it to the previous day’s event. The evidence therefore supports one measured disruption with a provider-supplied power explanation and a separate unexplained signal. Identifying the affected electricity circuits and telecommunications sites would help establish whether either event had the same underlying cause. [1] [10]

What remains unresolved

• Which September 29 EEC maintenance notice and affected circuits support Cloudflare’s explanation?
• Was the September 30 anomaly a separate interruption, and which networks experienced it?
• The archive uses the older label Swaziland for country code SZ; this article uses Eswatini.
• Telecom Observer calls September 29, 2026 a Monday, although the calendar date was Tuesday. Its explicit date and UTC window are preserved without adopting the weekday.
• The linked Cloudflare social post could not be fetched. The explanation is available in the supplied archived annotation, not independently recovered from that post.
• No precise independent IODA start or recovery time is supplied in the archive.

Fanap’s earlier outage and Iran’s newer anomalies remain unexplained

Fanap Telecom’s archived outage began before the observation week and ended 45 minutes into September 28. Cloudflare describes a complete disappearance of the network’s Internet traffic over two hours 45 minutes and assigns no cause. The matching FDI anomaly is the same episode, so it adds detail to the record without providing another independent observation. [1]

A September 29 public digest repeats the Fanap event and explicitly identifies Cloudflare Radar annotations as its source. It therefore adds no independent explanation or measurement. Searches for a contemporaneous operator account did not retrieve one, and the linked Cloudflare social post was inaccessible. The cause of this network-specific disruption remains unverified. The Vigilant. [12] [1]

New anomalies appeared on October 4 for MCCI, Fanap, TCI and Iran’s country traffic, with no end times in the archive. These are separate leads, not evidence that Fanap’s September outage continued or that Iran experienced uninterrupted nationwide loss. Their clustered starts warrant further investigation, but the available records do not establish a common cause, customer reach or recovery timeline. [1]

What remains unresolved

• What caused Fanap’s September 27 interruption, and is there an operator restoration account?
• Did the October 4 network signals reflect a shared incident, and when did each recover?
• FDI is AS206065; MCCI-AS is AS197207; TCI is AS58224.
• The four October 4 records carry the provider status TP. That status is preserved without interpreting it as proof of cause or nationwide impact.
• Null end times mean no endpoint was recorded in the supplied archive, not continuous loss through the archive generation time.
• The archived Fanap case lacks an independent measurement check; the public digest repeats the Cloudflare lineage.

Ukrainian network anomalies overlap earlier reports of data center disruption

The archive carries open anomalies for OT-AS and QOS beginning September 27, followed by another OT-AS record on September 29 with identical start and end timestamps. NetBlocks’ September 27 updates identify disruptions on the corresponding Omega Telecom and DreamLine networks. Those dated observations supply a second monitoring source for the earlier disruption, without establishing continuous loss during the following week. NetBlocks updates. [1] [13]

NetBlocks associated those September 27 disruptions with reported attacks on Kyiv data centers. Separately, TASS reported the Russian Defense Ministry’s claim that it had struck an Omega Telecom facility that afternoon. These are pre-week accounts relevant to the carried-over records. The ministry’s account remains a belligerent’s claim, and its timing cannot simply be substituted for the archived anomaly onset. NetBlocks, TASS. [13] [14]

The network identities make these reports more relevant than general news about attacks elsewhere in Ukraine. Even so, they do not explain the September 29 timestamp-only record or establish when customers recovered. The specific connection between each recorded anomaly and physical damage remains incomplete; an operator incident account would be needed to resolve the sequence and distinguish continuing disruption from a later signal. [1] [13] [14]

What remains unresolved

• When did Omega Telecom and DreamLine restore service, and what does the September 29 OT-AS record represent?
• OT-AS is AS199995, identified by NetBlocks as Omega Telecom; QOS is AS42352, identified in its chart as TOV Dream Line Holding.
• The two September 27 archive records have blank data-source fields and no endpoints.
• NetBlocks’ September 27 material was available in indexed page content; the direct homepage extraction omitted the embedded updates. No precise incident endpoints were retrieved.
• TASS quotes the ministry saying the strike occurred 'This afternoon' on September 27. No incident timezone is established, so no sourceWindows entry is created for that claim.
• The September 27 sources precede the observation week. They do not establish uninterrupted disruption during September 28 through October 4.
• The identical September 29 endpoints do not mean a zero-minute outage.

Taiwan network anomaly has a maintenance lead, but no established cause

Radar’s archive contains an unverified TFN-TW anomaly spanning late October 3 through October 4 UTC. A September 29 notice in National Tsing Hua University’s network service index announces Taiwan Fixed Network equipment maintenance for October 4. This is a specific provider and date match worth investigating, but the retrieved index provides no measured service-loss window. University notice index. [1] [15]

The maintenance notice does not establish that the work caused the full traffic anomaly, that it affected all customers, or that the university lost service. The archived signal remains a cause-unconfirmed lead. A detailed maintenance notice and a completion report would be needed to connect the planned work to the observed start, end and affected portions of the network. [1] [15]

What remains unresolved

• Which equipment and services were covered by the October 4 maintenance, and did its actual execution match the anomaly?
• The network identifier is AS9924; Radar marks the anomaly UNVERIFIED.
• The university index gives October 4, Sunday, without an incident time or explicit timezone. It is date-only context and receives no sourceWindows entry.
• No detailed maintenance completion account or independent measurement check was retrieved.

Republic of the Congo and Lesotho signals remain unexplained

Archived Radar measurements flag a 105-minute country anomaly in the Republic of the Congo on September 30 and a three-hour anomaly in Lesotho on October 4. The latter is marked unverified. Neither record names an affected operator or a cause, and neither supports a claim that all residents lost access. These are separate investigations grouped because their explanations remain unresolved. [1]

For Lesotho, Telecom Observer published two summaries with different recovery times: one describes 80 minutes, while another describes three hours beginning at the same time. Both leave the cause unexplained. Their sourcing is insufficient to count them as two independent observations, and neither reconciles its timing with Radar’s window. Shorter account, longer account. [16] [17] [1]

The available evidence does not identify which networks drove either country signal or demonstrate a connection between the two events. Lesotho’s recovery time needs reconciliation, while the Republic of the Congo lead still lacks a verified explanation. Operator notices or geographically specific measurements would be needed before describing either event’s practical reach or assigning a technical or political cause. [1] [16] [17]

What remains unresolved

• Which operators and locations account for the Republic of the Congo signal?
• Did Lesotho recover at 06:30 UTC, around 08:00 UTC, or at different times on different networks?
• The Congo archive record is CG, Republic of the Congo, not CD, Democratic Republic of the Congo.
• Telecom Observer’s longer Lesotho account calls October 4, 2026 a Monday; it was Sunday. Its explicit date and UTC times are retained without adopting the weekday.
• No independent country measurement check for these two anomalies is included in the supplied archive.

CANTV, Oceanwave and CAMNET anomalies lack verified explanations

Two CANTV anomalies on September 28 and 29 and an Oceanwave anomaly on October 2 have identical start and end timestamps in the archive. Their durations cannot be determined from those records. A separate CAMNET anomaly spans five hours on October 4 and is marked unverified. The country associations identify network registration, rather than measured geographic boundaries of customer impact. [1]

Research did not establish an operator explanation that could be matched to these specific signals. They remain separate, cause-unconfirmed leads. The immediate questions are whether the timestamp-only entries represent sustained customer disruption and which services contributed to CAMNET’s traffic change. Without that information, assigning a shared cause, national reach or customer outage duration would go beyond the available evidence. [1]

What remains unresolved

• Do the two CANTV entries represent distinct service interruptions, and what were their actual durations?
• What customer-visible event, if any, corresponds to Oceanwave’s October 2 timestamp-only record?
• Which CAMNET services and locations contributed to the October 4 anomaly?
• Network identifiers are CANTV AS8048, OCEANWAVE-AS-AP AS136442 and CAMNET-AS AS15964.
• Identical endpoints are archive properties, not proof of zero-minute outages.
• Radar marks the CANTV and Oceanwave records VERIFIED and CAMNET UNVERIFIED. These classifications do not establish causes or affected-person counts.

Sources and evidence

1. Cloudflare: Cloudflare Radar Outage Center. Supports: Public origin of the supplied archived five outage records and 30 anomalies. The consulted page identifies automatic anomalies and UTC timestamps; browser extraction did not expose the individual event rows. Event details and windows here come from the user-supplied archive, not newly collected measurements. [1]

2. Georgia Tech Internet Intelligence Lab: IODA Iraq dashboard. Supports: Public measurement origin for the archived Iraq checks. The dashboard was consulted but did not expose historical chart values in browser extraction. The supplied checks support country-level connectivity loss during the two Radar events, not individual operator impact or cause. [2]

3. Georgia Tech Internet Intelligence Lab: IODA Eswatini dashboard. Supports: Public measurement origin for the archived September 29 Eswatini active-probing check. Historical chart values were not exposed by browser extraction; the event finding comes from the supplied archive. [3]

4. Georgia Tech Internet Intelligence Lab: IODA data sources and detection glossary. Supports: Explains active probing, routing visibility and Merit telescope measurements, their aggregation by country or network, and the distinction between multiple signals and separate monitoring organizations. [4]

5. Le Facteur Haïti: Digicel disruption and reported international fiber problems (2026-10-03). Supports: Reports an October 3 morning disruption and attributes problems on two international fiber connections along Route Nationale 1 and repair work to Digicel chief executive Jean-Philippe Brun. [5]

6. Vant Bèf Info: Digicel customers report nearly 24 hours without Internet (2026-10-04). Supports: Reports effects on work, commerce, studies and communications, alongside customer requests for an explanation and restoration information. Does not provide a precise recovery time. [6]

7. Al Rabiaa TV: Education Ministry reschedules special-round examinations (2026-09-28). Supports: Indexed article text reports an Education Ministry statement rescheduling special-round examinations because of the September 30 through October 3 holiday. Provides examination context, not a shutdown directive. Direct page retrieval returned 403. [7]

8. Telecom Observer: Reported September 28 Iraq connectivity window (2026-09-28). Supports: Reports 03:30 to 04:10 UTC, differing from Radar’s 15-minute record. Underlying measurement provenance is insufficiently documented to count as an additional independent lineage. [8]

9. Telecom Observer: Reported October 4 Iraq connectivity window (2026-10-04). Supports: Reports 03:30 to 04:10 UTC and leaves the cause unexplained. Retained as a conflicting published window, not independent proof of the shutdown mechanism. [9]

10. Eswatini Electricity Company: EEC planned power outage notices. Supports: Primary utility page consulted for the claimed planned interruption. Retrieved content explains notification practices and lists a November 2025 notice, but provides no matching September 29, 2026 notice. [10]

11. Telecom Observer: Reported September 29 Eswatini connectivity window (2026-09-29). Supports: Reports approximately 10:50 to 12:30 UTC with cause unassigned. Its weekday is inconsistent with its explicit date; its measurement provenance does not establish an additional independent lineage. [11]

12. The Vigilant: September 29 digest repeating Radar’s Fanap annotation (2026-09-29). Supports: Repeats the Fanap disruption and explicitly sources Internet disruption entries to Cloudflare Radar annotations. Demonstrates a shared source lineage, not independent confirmation or explanation. [12]

13. NetBlocks: NetBlocks September 27 Ukraine network updates. Supports: Indexed homepage updates dated September 27 identify disruptions on Omega Telecom AS199995 and Dream Line Holding AS42352 and associate them with reported Kyiv data center attacks. These precede the observation week. The rolling page has no single publication date, and direct extraction omitted embedded updates. [13]

14. TASS: Russian ministry claims strike on Omega Telecom facility (2026-09-27). Supports: Reports the Russian Defense Ministry’s claim of an afternoon strike on an Omega Telecom data center. Used as a dated claim, not independent verification of physical damage, military use or the cause of each anomaly. [14]

15. National Tsing Hua University network systems group: University index lists October 4 Taiwan Fixed Network maintenance. Supports: Rolling notice index contains an entry posted September 29, 2026 announcing Taiwan Fixed Network equipment maintenance on October 4. Establishes a dated maintenance lead only; no detailed incident times or demonstrated connection to AS9924’s full anomaly were retrieved. [15]

16. Telecom Observer: Lesotho disruption reported as 80 minutes (2026-10-04). Supports: Reports an October 4 window of 05:10 to 06:30 UTC without an established cause. One of two conflicting accounts from the same publisher. [16]

17. Telecom Observer: Lesotho disruption reported as three hours (2026-10-04). Supports: Reports an October 4 window of 05:10 to 08:10 UTC without an established cause. Its weekday is erroneous; the explicit date and UTC times are preserved. [17]

Method and reporting window

This issue covers records overlapping 2026-09-28T00:00:00.000Z through 2026-10-05T00:00:00.000Z, with the end excluded. The evidence snapshot was assembled at 2026-10-05T13:00:02.735Z. 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.