Early on Tuesday, October 20, a power event in one of the three availability zones in Google Cloud's London region took services offline across the UK. Revolut customers lost card payments, transfers and sign-in. HM Courts & Tribunals Service had problems with the cloud video platform it uses for remote hearings, and at Southwark Crown Court a judge told the court there had been "problems with Google". By early afternoon Google said it was seeing "recovery of services for most workloads".
For the companies whose services went down, the cause was confirmed within hours. For IT teams everywhere else, the morning posed a harder question. Users were reporting problems. Was it the cloud, the internet path in between, or their own network?
The attribution problem
The same morning, users reported problems with Lloyds Bank, HSBC, Royal Mail, DPD and Rightmove on Downdetector. The Press Association's coverage was careful to say it was unclear whether all of those issues were connected to the Google outage. Some were confirmed. The budgeting app Emma posted that it was "up and running again after this morning's Google Cloud power outage in London." Others never named a cause.
That uncertainty is normal, and it's the real lesson of the day. Complaint trackers tell you users are unhappy. A provider's status page tells you what the provider has confirmed, which always trails what users are experiencing. Neither tells you where the fault is, and the gap between them is where help desks spend the first hour of most incidents.
Three places a problem can be
When a cloud-hosted application misbehaves, the cause usually sits in one of three places:
- Your own network. Wi-Fi, the LAN, the firewall, the office's internet edge.
- The path. Your ISP, the transit carriers and the peering points between you and the provider. You don't own any of it, and neither does the provider.
- The provider. The data center, the platform or the application. On October 20 it was here.
Each has a different owner and a different fix. Escalating a provider outage to your ISP wastes time. Refreshing a provider's status page while your own firewall drops packets wastes more.
The useful skill is ruling out the first two quickly. If you can say, with evidence, that your network and the path to the provider are clean, the problem is the provider's, and the conversation moves to workarounds. Google's own advice on the day was for customers to "try to migrate their workload impacted to another available location (zone or region)." That's a decision you can only make with confidence once you know the network isn't the issue.
What dashboards don't tell you
Most organizations have plenty of monitoring. Device counters, interface utilization and application logs each report from a single point. They describe the health of a box, not the experience of traffic moving end to end. A router can show low utilization while the path beyond it drops one packet in fifty.
Real-time applications make the gap wider. A video hearing or a VoIP call needs little bandwidth, but it needs packets to arrive on time and in order. A connection that passes a speed test can still freeze video when jitter or packet loss rises, which is why latency and consistency of service matter more to the user than the headline speed. "The internet is up" and "video calls work" are different claims, and only the first is easy to check.
Measure the path before you need to
The way to close the attribution gap is to measure the path actively and continuously, before anything goes wrong:
- Test end to end, not from one point. Send real traffic between known endpoints, such as an office and a test point close to the cloud region you depend on, and measure round-trip time, jitter and loss in both directions.
- Keep a baseline. A measurement taken during an incident means little without knowing what normal looks like on that path at that time of day.
- Trace the route both ways. Outbound and return paths often differ, and a problem on the return path is invisible to a standard traceroute.
- Test what the business runs on. If it depends on calls and video, test with media-like traffic, not just a file download.
With that in place, a morning like October 20 answers its own question in minutes. If tests between your offices and the region are clean while the application fails, the fault is upstream of your network, and you can say so.
Where MyConnection Server fits
MyConnection Server is built for this kind of measurement. Network Connection Satellites, as hardware appliances or as software on servers and cloud instances, run scheduled tests to each other: VoIP and video quality, TCP throughput, UDP capacity and bidirectional traceroute. Results build a baseline over time, and threshold alerts flag when jitter, loss or MOS cross the limits you set. MCS doesn't monitor your applications and it doesn't fix the network. It tells you, with evidence, whether the network path is healthy, which is the first question that needs answering on a morning like this one.
In conclusion
The October 20 outage was the provider's, and Google said so and apologized. Most incidents are less obliging. The cause is rarely announced, and the first hour goes to working out whose problem it is. Organizations that measure their own paths continuously can answer "is it us?" from data. The rest are left reading complaint trackers.
Sources: details of the outage are from The Register, October 20, 2026 and the Press Association's report as published in The Irish News, October 20, 2026. Google has said it will publish a full analysis of the incident. Accurate as of October 24, 2026.