Google Cloud power outage and Orange mobile failure lead a week of disruptions

Google Cloud reported a power interruption in its London infrastructure, while Orange confirmed a mobile core equipment failure affecting calls, messages and data in France. Elsewhere, operators described storm recovery in Guam and planned maintenance in Syria. Reporting connected power disruptions with connectivity trouble in Ukraine, while VK disputed service impact after acknowledging a drone attack. This review covers October 19 through 25, including incidents crossing the week's boundaries. It preserves differences between measured traffic recovery, operator incident windows and customer experience, and leaves unsupported causes unresolved. [1] [3] [4] [5] [2] [8]

Google's London outage has two recovery clocks

Archived Cloudflare measurements show an 8 hour 15 minute disruption associated with Google Cloud's London region on October 20. The outage and origin-traffic anomaly share the same window and are treated here as one incident. This observation concerns traffic reaching cloud infrastructure, rather than a loss of internet access throughout London. [1]

Google's October 22 preliminary report attributes the incident to a power interruption in the europe-west2-b zone, with secondary delays elsewhere in the region. It gives a 6 hour 10 minute window, shorter than Radar's. Earlier updates used a different start estimate and subsequently acknowledged residual customer impact after most services recovered. [3]

The different endpoints should remain visible. Google's infrastructure incident window and Radar's traffic observation describe different aspects of recovery, and neither supplies a complete customer timeline. The unresolved operational question is which services or customers continued to experience problems after Google's revised endpoint, and whether those problems explain the longer traffic window. [1] [3]

What remains unresolved

• Which services or customers remained affected after Google's revised incident endpoint?
• Radar's window is 2026-10-20T05:45:00Z to 2026-10-20T14:00:00Z. Google's October 22 preliminary report gives 2026-10-20T06:00:00Z to 2026-10-20T12:10:00Z.
• Earlier Google updates gave the start as October 19 at 23:08 PDT. The October 20 update at 07:03 PDT said most customers had recovered but a small number remained affected.
• The preliminary report is an operator explanation subject to revision. The archive contains no independent IODA check for this platform incident.

Orange confirms a mobile core failure, with recovery extending into the evening

Radar's archived Orange record spans seven hours on October 21, with a matching network traffic anomaly. That measurement establishes a period of abnormal traffic associated with Orange's network. The identification of mobile services, the customer impact and the technical explanation come from Orange's statements and reporting, rather than from the network identifier alone. [1]

Orange's initial statement said the incident severely disrupted calls, SMS and mobile usage for a substantial portion of residential and business customers. Its restoration announcement attributed the problem to equipment failure in the mobile core network. The operator said services were operational again and that technical teams would continue monitoring their stability. [4] [5]

Les Numériques described roughly nine hours of disruption, reporting problems from around "11h30" and carrying Orange's restoration message in an update marked "21/10/2026 à 20:51." Those displayed times have no explicit timezone, so they remain unconverted. This longer account leaves a practical question: when did the last affected customers regain reliable service after Radar's traffic window ended? [6] [1]

What remains unresolved

• When did the last affected customer groups regain reliable calls, SMS and mobile data?
• AS3215 identifies the archived network; its French registration is not itself an impact boundary.
• Les Numériques reports an onset around '11h30', a roughly nine-hour incident and an update at '21/10/2026 à 20:51'. Its timezone is not explicit, and the update timestamp is not necessarily the restoration instant. No sourceWindows entry is inferred.
• Orange's October 21 statements are date-only notices and do not supply a precise incident window.
• The sources do not establish that every Orange subscriber or fixed broadband connection was affected.

Guam's storm recovery continued into the observation week

Radar's Guam disruption began before the observation week and ended on October 20, spanning 67 hours in the archive. It names three networks and several island regions, and attributes the disruption to Super Typhoon Champi. That broad record does not establish that every household or business remained continuously disconnected for the full period. [1]

DOCOMO PACIFIC's recovery page provides direct operator evidence of storm-related service trouble. Its update headed "Monday, October 19, 2026 | 11:30am" says engineering and field teams were assessing damage, repairing infrastructure and restoring connectivity. The company said restoration priorities included critical infrastructure, public safety and areas with the greatest customer impact. The displayed time has no explicit timezone. [7]

The operator notice supports the storm-recovery account, but it does not validate Radar's precise window or the experience of each named network. Archived IODA results supplied only routing information for Guam, without an independent reachability-loss signal. The remaining question is how restoration progressed by service and locality, particularly for customers still disconnected as aggregate traffic recovered. [1] [2] [7]

What remains unresolved

• How did restoration progress by locality and service, and did customer outages persist after Radar's endpoint?
• Radar names AS3605 ERX-KUENTOS-AS, AS395400 UNIVERSITY-GUAM and AS9246 GTA-AP. DOCOMO's notice concerns its own operations and does not independently verify all three network records.
• DOCOMO's notice displays 'Monday, October 19, 2026 | 11:30am' without an explicit timezone. It is not converted into a source window.
• The archived IODA result contains BGP information only. Routing changes alone do not establish lost end-user reachability.
• The 67-hour record includes time before the observation week and is not a measured duration of uninterrupted island-wide loss.

Syria's brief disruption coincided with announced maintenance

Radar records a 45-minute disruption in Syria on October 19 and a shorter, overlapping anomaly on one Syrian Telecom network. Archived IODA active probing also detected lost reachability at country level during the outage window. This second monitor supports the existence of a disruption, without establishing the experience of every operator named in Radar's record. [1] [2]

SANA reported an announcement supplied by Syrian Telecom on October 19: maintenance and upgrades to internet equipment in Damascus could cause interruptions from midnight Monday until 7 a.m. Tuesday. The notice provides a contemporaneous explanation consistent with Radar's maintenance classification. Its stated schedule is a work window, however, rather than a measurement of continuous service loss. [8]

The available evidence supports a brief connectivity disruption alongside announced maintenance. It leaves the detailed relationship unresolved: the notice concerns equipment in Damascus, while Radar names several regions and providers. An operator completion report would help establish which maintenance operation affected which services, and why the observed traffic disruption occupied only part of the announced work period. [1] [2] [8]

What remains unresolved

• Which maintenance operation affected the named providers, and when did each service recover?
• Radar names AS201550 EXT-PDN-STE-AS, AS29256 INT-PDN-STE-AS and AS48065 Syriatel-AS. IODA's country-level active probing does not independently establish impact on each network.
• SANA's October 19 notice says midnight Monday through 7 a.m. Tuesday without an explicit timezone. That wording is preserved without an inferred ISO window.
• The shorter AS29256 anomaly is nested within the outage record; it is not an additional independent outage.
• Exact IODA alert endpoints were not supplied in the archive and are not reconstructed from Radar's window.

Power disruption accompanies two separate regional internet incidents

Radar records separate disruptions in Zhytomyr Oblast and in Russian-occupied Crimea and Sevastopol. The first spans October 22 through 24; the second spans October 23 through 25. Radar attributes both to strikes on energy infrastructure, identifying different attacking parties. The records name no affected internet operators and should not be combined into one continuous Ukrainian outage. [1]

Zhytomyr.info's October 23 reporting quotes the regional electricity distributor saying attacks on energy infrastructure had forced emergency disconnections and invalidated normal outage schedules. It also documents warnings issued on October 22 about prolonged power interruptions. This supports the local power-disruption context, but does not identify the telecommunications equipment behind Radar's regional traffic decline. [9]

For Crimea, the Kyiv Independent reported on October 24 that occupation authorities acknowledged power outages following an attack on energy infrastructure. It also cited NetBlocks reporting widespread internet disruption. Officials subsequently claimed power restoration, while local accounts described renewed blackouts. The newspaper explicitly said it could not independently verify the full extent of the outages or reported attacks. [10]

Power failures offer a supported explanation to investigate in both places, but the evidence does not map each strike to each internet interruption. The archived IODA checks returned no Ukrainian alerts during these windows, which does not rule out regional failures. The central unresolved question is whether traffic recovered alongside electricity, or whether damaged communications infrastructure prolonged some customers' outages. [1] [2] [9] [10]

What remains unresolved

• Did internet recovery follow electricity restoration, or did communications damage extend the disruption?
• Radar's Zhytomyr window lasts 44 hours 15 minutes; its Crimea and Sevastopol window lasts 30 hours 45 minutes. Neither establishes uninterrupted loss for every resident.
• The Kyiv Independent's NetBlocks reference is a separately reported measurement source, but the original post was not retrievable during this review. It is not treated as a newly inspected measurement series.
• Claims of power restoration and reports of renewed blackouts in Crimea remain distinct; neither supplies a precise internet restoration endpoint.
• The regional reporting provides dated context, not timezone-explicit measured windows.
• No country-level IODA alert in the archived checks does not establish that the regional outages were absent.

VK acknowledged an attack but disputed service impact

Radar's VK network outage and matching anomaly begin on October 18, before the observation week, and have no recorded endpoint in the archive. Radar describes disruption following a data center drone strike and classifies the cause as military action. The open record does not establish that VK's services were continuously unavailable throughout the following week. [1]

The Record reported on October 19 that VK acknowledged a drone attack on its Leningrad-region facility but said its services remained normally available. The same article described user complaints about feeds and music, alongside monitoring evidence of reduced connectivity. It explicitly left unresolved whether those service problems were caused by the strike. [11]

These accounts support an attack acknowledgment and evidence of service trouble, while preserving a material disagreement about their connection. Repetition of VK's statement by other outlets would not resolve that disagreement. The missing evidence is a service-level incident timeline showing what failed, which users were affected and whether recovery depended on repairs at the targeted facility. [1] [11]

What remains unresolved

• Were the observed service problems caused by damage at the targeted facility, and when did affected services recover?
• The network is AS47541. Its Russian registration country is not a measured geographic boundary.
• The null endpoint is an open archive record, not evidence of uninterrupted platform-wide or nationwide unavailability.
• VK's acknowledgment and denial of service impact are available here through The Record's reporting; the linked original statement could not be retrieved.
• The outage and anomaly share a start and network and are treated as one story, not two independent observations.

Three DON-FTTH interruptions remain without a verified explanation

Radar records three separate DON-FTTH interruptions between October 19 and 21, lasting 6 hours 15 minutes, 1 hour 15 minutes and 8 hours 45 minutes. Each has a matching anomaly with the same boundaries. The gaps between them matter: these records describe repeated interruptions on one network, rather than a single continuous outage. [1]

Radar classifies all three as military action, but supplies no linked explanation in these records. Searches for the network and operator did not locate an event-specific notice establishing that cause. The classification therefore remains a provider claim. The unresolved question is whether one recurring fault produced all three interruptions, and which customer locations experienced service loss. [1]

What remains unresolved

• Did one recurring fault produce the three interruptions, and which customer locations were affected?
• AS41039 is the network identifier. Registration information does not establish the location of the observed disruption.
• No independently verified cause or event-specific operator explanation was found.
• The three matching anomalies are duplicate views of the archived outage windows, not three additional incidents.
• The archive has no independent reachability check for these network-specific records.

Armstrong reporting confirms service trouble, but customer timelines differ

Radar's Armstrong record spans two hours across October 21 and 22 in UTC, with a matching ACS-INTERNET anomaly. Its description names customers in Pennsylvania, Ohio, New York and Kentucky. This establishes the provider's reported scope, while local reporting offers a separate account of service trouble and recovery around the same evening. [1]

Butler Radio reported on October 22 that most internet coverage had returned after disruption beginning around "6 p.m." the previous evening. Citing Armstrong, it described an issue within the company's network. Butler Eagle separately reported complaints between "6 and 8 p.m." and interviewed a customer who said his internet and television remained unavailable Thursday afternoon. Neither report explicitly specifies the timezone. [12] [13]

The reporting supports a service incident, but the broad explanation of a network issue does not establish a root cause. The customer's longer outage also cannot automatically be assigned to the same failure. What remains unresolved is whether residual service problems followed the shared incident, or whether separate local faults overlapped with the two-hour traffic disruption. [1] [12] [13]

What remains unresolved

• Were longer customer outages residual effects of the shared incident or separate local failures?
• AS27364 identifies ACS-INTERNET in the archive; Radar identifies the customer-facing operator as Armstrong.
• Butler Radio says 'around 6 p.m.' on October 21. Butler Eagle says 'between 6 and 8 p.m.' and reports one customer's outage from noon Wednesday into Thursday afternoon. Neither source explicitly specifies a timezone, so these accounts are not converted into source windows.
• The reported company statement identifies a network issue but does not disclose the failed component or root cause.
• The four-state scope comes from Radar and was not independently verified state by state.

Eight additional traffic signals remain unexplained

Additional network signals include a six-hour TELE2-RU-AS anomaly spanning October 19 and 20, and a 12 hour 15 minute FDI anomaly on October 21. TCI also has an October 21 entry whose start and end are identical. These are separate automated leads; the available evidence does not establish a shared incident or cause. [1]

Gabon has a country-level anomaly lasting 5 hours 30 minutes on October 20. The Republic of the Congo has two entries, on October 21 and 22, each with identical start and end timestamps. Those entries do not establish zero-minute outages, and their country code identifies Congo-Brazzaville, not the Democratic Republic of the Congo. [1]

IQ-Online's anomaly spans 1 hour 45 minutes on October 22. Digicel Haiti's begins late on October 25 and ends 15 minutes beyond the observation week's boundary, for a recorded span of 90 minutes. Both are network-specific signals. Neither record establishes nationwide loss of access or supplies a cause for the observed traffic change. [1]

Public-source searches did not establish explanations tied to these particular internet signals. They remain leads rather than confirmed accounts of customer outages. The next useful evidence would be operator notices or independent measurements identifying affected services and places, together with clarification of the equal-timestamp entries. Unrelated national news cannot answer those questions. [1]

What remains unresolved

• For TELE2-RU-AS, did the measured traffic change correspond to loss of internet service, and where?
• For Gabon, which networks and services contributed to the country-level signal?
• For TCI and both Republic of the Congo entries, what do the identical start and end timestamps represent?
• For FDI and IQ-Online, which customer services were affected and what caused the changes?
• For Digicel Haiti, was the traffic anomaly associated with a customer outage, and did service recovery coincide with the recorded endpoint?
• Network identifiers are AS15378 for TELE2-RU-AS, AS58224 for TCI, AS206065 for FDI, AS48492 for IQ-Online and AS27653 for Digicel Haiti. Registration countries do not establish outage geography.
• Radar's TP and VERIFIED labels are provider metadata, not independent verification of cause, duration or customer impact.
• The Republic of the Congo records use CG. They must not be combined with reporting about the Democratic Republic of the Congo, CD.
• Digicel's endpoint is outside the observation week and is retained as a boundary-crossing record, not counted as wholly in-week duration.

Sources and evidence

1. Cloudflare: Cloudflare Radar Outage Center. Supports: Origin of the supplied archived outage and anomaly records, including windows, network identifiers and provider classifications. The public page was consulted; historical record details come from the supplied archive, not newly collected first-party measurements. [1]

2. Georgia Tech Internet Intelligence Lab: IODA internet connectivity monitoring. Supports: Origin of archived IODA checks: active-probing support for Syria, BGP-only information for Guam and no returned Ukrainian alerts in the specified windows. The public interface was consulted, but the archived results were not independently reconstructed. [2]

3. Google Cloud: Google Cloud London incident and preliminary report (2026-10-20). Supports: Operator updates on October 20 and a preliminary report on October 22 describing power disruption, revised incident times, regional effects and residual customer impact. [3]

4. Orange: Orange announces major mobile network incident (2026-10-21). Supports: Original operator statement identifying disruption to calls, SMS and mobile usage for a substantial portion of residential and business customers. [4]

5. Orange: Orange announces mobile service restoration (2026-10-21). Supports: Original restoration announcement and attribution to equipment failure in the mobile core network. [5]

6. Les Numériques: Orange mobile outage reported as lasting about nine hours (2026-10-21). Supports: Contemporaneous reporting of onset around 11h30 and a restoration update displayed at 20:51, without an explicit timezone. [6]

7. DOCOMO PACIFIC: DOCOMO PACIFIC Typhoon Champi recovery update (2026-10-19). Supports: Direct operator notice describing damage assessment, infrastructure repair, service restoration and recovery priorities. [7]

8. Syrian Arab News Agency: Syrian Telecom announces overnight internet maintenance in Damascus (2026-10-19). Supports: Syrian Telecom statement supplied to SANA announcing maintenance from midnight Monday to 7 a.m. Tuesday and possible interruptions; timezone not explicitly stated. [8]

9. Zhytomyr.info: Zhytomyr electricity distributor reports emergency disconnections (2026-10-23). Supports: Local reporting quoting the electricity distributor and documenting October 22 and 23 power disruption warnings following attacks. [9]

10. The Kyiv Independent: Power and internet disruptions reported in occupied Crimea (2026-10-24). Supports: Reporting of official power-outage acknowledgments, a NetBlocks internet-disruption report and conflicting restoration accounts, with explicit verification limits. [10]

11. The Record: VK disputes service impact after acknowledged data center attack (2026-10-19). Supports: Reporting of VK's attack acknowledgment and service-impact denial, user complaints and monitoring evidence; the causal connection remains unresolved. [11]

12. Butler Radio Network: Armstrong service restored after evening outage (2026-10-22). Supports: Local reporting citing Armstrong's explanation of an internal network issue and describing service restoration. [12]

13. Butler Eagle: Armstrong customers report service problems and differing recovery times (2026-10-22). Supports: Original local reporting of evening complaint activity and an interview with a customer reporting a longer outage. [13]

Method and reporting window

This issue covers records overlapping 2026-10-19T00:00:00.000Z through 2026-10-26T00:00:00.000Z, with the end excluded. The evidence snapshot was assembled at 2026-10-26T16:00:09.292Z. 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.