Google’s London cloud outage interrupted payments and court hearings

A cloud outage became a payments and courtroom problem on October 20. The Guardian reported disrupted banking services at lenders including Lloyds and Revolut, affecting card payments, cash withdrawals and transfers. It also reported that the video system used for remote court appearances across England and Wales failed throughout the morning. [1]

For an affected customer, the practical problem is being unable to finish something: move money, make a payment or participate in a hearing. That is how an infrastructure interruption can become an economic cost for organizations that do very different work. The relevant unit is blocked work and the effort needed to recover it.

Google attributed the incident to a power event in europe-west2-b, a zone in its London region. Its account distinguishes unavailable services in that zone from elevated errors and intermittent network problems in some services across the wider region. It does not describe the entire London region as unavailable. [2]

Google lists the incident from October 19 at 23:08 to October 20 at 07:00 US/Pacific. Adding seven hours to convert Pacific daylight time to UTC gives October 20, 06:08–14:00: an interval of seven hours and 52 minutes. That is the incident’s recorded span, not a claim that every customer was unable to operate for that long. [2]

In its closing update, Google said the issue had been mitigated for most customers but was believed still to affect a very small number. A closed incident interval therefore did not mean every customer had recovered. [2]

The first potential bill sits with service operators: support requests, recovery work and time spent restoring transactions or access. Users can bear a second cost through delay. Those are plausible consequences of interrupted workflows, not measured losses in this incident; a delayed transaction is not automatically revenue permanently lost.

The spending question is equally specific. More backup capacity is valuable only if it lets the important workflow continue when a dependency fails. The reported interruptions do not reveal these customers’ configurations, prove their backup arrangements all failed, or show that moving to another provider would have prevented the problem.

The strongest counterargument is that this was a temporary fault followed by substantial recovery, with delayed work potentially completed later rather than permanently lost. If customer services returned quickly and cleared delayed work with little extra effort, the economic impact would be much smaller than the breadth of the outage headlines suggests.

Google said it would publish an analysis after completing its internal investigation. [2]

That account matters most if it explains which dependencies spread the interruption and how restoration reached customer services. Watch it alongside customer reports of payment completion and court access returning, including residual cases. The useful resilience test is time to usable service—not simply time to an infrastructure status change.