Google Cloud has explained why its backup generators never started during the 20 October power failure in London that disrupted UK banks, Royal Mail and the courts. In an update to its service status page on 4 November 2026, the company said the outage at the europe–west2–b zone began with an external underground cable fault on the site’s primary utility feeder. The second, independent feeder was already out of service for planned repairs. Battery backup kept systems running for about five minutes — and then the generators, which should have taken over, never received the signal to start.
The reason, according to Google, was a “voltage–sensing design flaw and PLC misconfiguration”. The programmable logic controller that manages the generator plant incorrectly concluded that a healthy utility supply was still available, even though both distribution feeds were de–energised. No automatic start command was issued. When the batteries ran down, the critical load was lost.
It is a detailed and candid account, and it tells a story that every organisation relying on cloud services should take seriously. The site was designed so that no single fault could take it down. In practice, routine maintenance, a genuine cable failure and a software logic error lined up, and defences that looked robust on paper were defeated one after another.
How the site was meant to work
The London facility uses what Google describes as a “2N” power architecture. In simple terms, everything is duplicated. There are two fully independent utility feeds, known as Feeder A and Feeder B, each capable of supporting the site. Behind them sits a central high–voltage generator bank, controlled by a dual–redundant programmable logic controller (PLC). Between the mains supply and the servers, uninterruptible power supplies (UPS) provide battery power for the short period needed for generators to start and take the load.
The design principle is that no single point of failure should ever take the site down. Lose one feeder, and the other carries the load. Lose both, and the UPS bridges the gap while the PLC tells the generators to start. Each layer is meant to cover the failure of the one before it.
What actually happened
The chain of events, as Google describes it, ran as follows.
During a routine quarterly generator load test, issues were identified that needed corrective repairs. To allow that work, Feeder B’s circuit breaker was deliberately opened on 14 October 2026. From that point, Feeder A alone was supporting the entire critical load. That is a normal, planned state during maintenance — the generators were still there as the backup.
On 20 October, Feeder A’s external underground cable, supplied by the site’s power company, developed a fault. With Feeder B already open, the site lost its utility supply. The UPS systems activated exactly as designed and kept everything running for about five minutes, which is the time they are built to cover.
The generators should have started within that window. They did not, because the PLC never told them to. A voltage–sensing design flaw combined with a misconfiguration caused the PLC logic to indicate that a healthy utility source was still available. As far as the controller was concerned, there was no emergency. When the UPS batteries were exhausted, the critical load was lost.
The effects reached far beyond the data centre. The outage disrupted Lloyds, HSBC, Barclays, NatWest, Royal Mail, Revolut and the Ministry of Justice’s court video platform, among others. Our original report on the day of the outage and the single–region problem set out how widely the disruption was felt.
The London site had two feeds, a generator bank, a dual–redundant controller and battery backup. On paper that is a robust design. In practice, one feed was out for maintenance, the other suffered a real fault and the controller’s logic failed to recognise what was happening. The same pattern applies to your own systems: a backup internet line that has never been tested, a server replica that silently stopped syncing, a cloud backup nobody has restored from. If you have not tested a failover recently, you do not know whether it works.
How the account fits with earlier reporting
At the time of the outage, UK Power Networks said its London electricity systems had run normally throughout. Google’s update now attributes the trigger to an external underground cable fault on the feeder supplying the site. The two statements are not necessarily in conflict: a fault on a single feeder cable serving one facility need not affect the wider distribution network. Either way, Google’s own account is clear that the outage resulted from the site’s failure to start its generators once the utility supply was lost, not from the cable fault alone.
The sequence, step by step
The timeline below is drawn from Google’s post–incident update and the reporting around it. Where no exact time was given, the step is described rather than timed.
What Google has changed
Google says it has reprogrammed the PLC logic to prevent the same failure mode from recurring, made further changes to the site’s electrical configuration and tested those changes to confirm they work as intended.
It has also committed to two broader follow–up actions:
- A “Communications Enhancement”. Google will build an automated alert–to–communication mechanism for incidents that affect a whole location, so that customers are notified faster.
- Expanded failure testing. Google will extend platform–wide testing of infrastructure–level failure scenarios beyond this specific site.
Both commitments address real weaknesses. Faster notification matters because, in an incident like this, customers can find out from their own users before any official update reaches them. And the fact that a latent logic error could sit undetected in a generator controller suggests that testing had not covered this precise combination of conditions. Whether the changes are enough will only be proven over time, but the direction is right.
Three lessons from the root cause
Maintenance quietly removes redundancy
For six days, the site was running on a single utility feed. That was deliberate, planned and entirely normal for maintenance — but it meant the site’s resilience rested on the generators working first time if anything happened to Feeder A. The same thing happens in every IT environment: a server taken offline for patching, a backup line disconnected during an office move, a replica paused during an upgrade. During those windows, you are less resilient than your design suggests.
Control logic can fail silently
The generators were physically available. The batteries worked. The failure was in the logic that decides when to act. A controller that wrongly believes everything is fine is in some ways worse than one that fails loudly, because nothing alerts anyone until it is too late. Software that monitors and switches systems — failover scripts, health checks, backup schedulers — deserves the same scrutiny as the systems it protects.
Test the combination, not just the parts
Each component was presumably tested. The quarterly load test, after all, was what identified the issues on Feeder B. But the specific combination — one feed open, the other failing, the controller misreading voltage — was not caught. Google’s commitment to expanded infrastructure–level failure testing recognises this. For smaller organisations, the equivalent is testing realistic scenarios end to end: not “does the backup exist?” but “can we restore from it on a bad day, with one system already down?”
What protects a business from a provider outage
No business can fix a cloud provider’s generator logic. What it can control is how much it depends on any one zone, region or provider, and how quickly it can recover. The chart below is our indicative assessment — not measured data — of how much each measure reduces a smaller UK business’s exposure to an outage like this one.
The bottom bar is the assumption this incident challenges most directly. Google’s site was built with extensive redundancy, and it still failed. That is not a reason to distrust cloud providers — they generally run infrastructure far more reliably than most organisations could themselves — but it is a reason not to treat their redundancy as your continuity plan.
Multi–zone deployment sits in the middle for a reason. It protects against many failures, but our earlier coverage noted that the other London zones did not fully absorb the load on 20 October, and europe–west2 is Google’s only UK region. Independent backups and the ability to run elsewhere give more protection, especially for systems that must keep working.
A cloud resilience score card
The score card below rates common positions for UK businesses that depend on public cloud services, directly or through suppliers. It is a judgement framework for planning, not an audit.
The last row connects directly to Google’s communications commitment. Providers are working to notify customers faster, but businesses should not rely on that alone. Simple independent monitoring of your own key services will often tell you something is wrong before any status page does.
What resilience costs a smaller business
The figures below are indicative ranges for a smaller UK business that relies on cloud services for key systems. They are planning estimates rather than quotations, and they vary with data volumes and how systems are built.
| Measure | Indicative one–off cost | Indicative ongoing cost | What it addresses |
|---|---|---|---|
| Cloud dependency and continuity review | £750–£3,000 | Reviewed annually | Knowing which systems and suppliers depend on which provider and region |
| Independent backup to a second provider or location | £300–£1,500 to set up | £30–£300 per month, depending on data volume | Data remains recoverable if the primary provider or zone is down |
| Microsoft 365 or Google Workspace backup | £0–£500 to set up | £2–£5 per user per month | Email and files protected outside the platform itself |
| Multi–zone deployment for critical applications | £1,000–£8,000 | Additional hosting, often 20–60% more | Survives many single–zone failures |
| Warm standby in a second region or provider | £3,000–£20,000 | £200–£2,000 per month | Allows critical services to keep running during a regional outage |
| Scheduled restore and failover tests | £500–£2,000 per test | Twice a year | Proves the plan works before it is needed |
| Independent uptime monitoring | £0–£200 to set up | £10–£100 per month | Early warning without waiting for a provider’s status page |
Not every business needs a warm standby. For many, independent backups, a tested restore process and a clear manual workaround for a day of disruption are proportionate. The right level depends on how long you can operate without a system, and what an hour of downtime costs.
Relying on the provider versus planning for its failure
Provider redundancy only
Common, and usually fine — until it is not
Planned for provider failure
What the London outage argues for
The left column is not careless. Cloud providers are extremely reliable most of the time, and building redundancy costs money. But the London outage shows that “most of the time” is not “all of the time”, and that even carefully engineered sites can fail in unexpected ways.
How prepared are smaller UK businesses?
The gauge below is our indicative estimate of how well a typical smaller UK business could keep working, or recover quickly, if its main cloud provider suffered an outage like the one on 20 October. It is a judgement based on the score card patterns, not a survey result.
A score of 30 reflects how many smaller organisations use the cloud: as a single platform for everything, with backups inside the same service and a reasonable but untested assumption that the provider will handle any failure. The gap is not usually technology. It is planning and testing.
Google’s outage hit while one layer of protection was already out for maintenance. Ask the same question of your own systems: if one backup or failover route is unavailable, what happens when the main one fails? Then test it. Restore a real file, a mailbox or a database from your independent backup to a separate location, time how long it takes and note what went wrong. A restore you have done once is worth far more than a backup you have never touched.
Analysis: credit for candour, and a lesson in layered failure
Google deserves credit for publishing a detailed root cause. It would have been easy to stop at “a power issue”. Instead, the company has explained the maintenance state, the cable fault, the controller’s logic error and the five–minute UPS window, and it has said what it has fixed. That transparency helps customers understand their own risk.
The account also confirms something resilience engineers have long known: serious outages rarely have a single cause. Here, three separate conditions were needed — Feeder B open, Feeder A failing and the PLC misreading the situation. Any one of them alone would probably have been harmless. Together, they defeated a design that looked robust.
For UK businesses, the strategic question remains the one raised on the day. Europe–west2 is Google’s only UK region, and the other London zones did not fully absorb the load. Organisations with UK data residency requirements face a real trade–off between keeping data in the UK and spreading risk across regions. Our reports on local opposition to new UK data centres and the Azure ExpressRoute and VPN outage explore other angles of the same concentration risk.
The answer for most smaller businesses is not to abandon a provider. It is to hold an independent copy of what matters, know how long recovery would take and make sure that a bad day at one data centre does not become a bad week for the business.
At a glance
| Item | Detail |
|---|---|
| Incident | Power failure at Google Cloud europe–west2–b, London, on 20 October 2026 |
| Root cause published | 4 November 2026, on Google Cloud’s service status page |
| Trigger | External underground cable fault on primary utility Feeder A |
| Second feed | Feeder B deliberately opened on 14 October for repairs after a quarterly generator load test |
| Battery backup | UPS kept systems running for about five minutes, as designed |
| Why generators did not start | Voltage–sensing design flaw and PLC misconfiguration indicated a healthy supply was still available |
| Result | Critical load lost when UPS batteries were depleted |
| Organisations affected | Lloyds, HSBC, Barclays, NatWest, Royal Mail, Revolut and the Ministry of Justice’s court video platform, among others |
| Fixes | PLC logic reprogrammed, electrical configuration changed and changes tested |
| Follow–up actions | Automated alert–to–communication for location incidents; wider infrastructure failure testing |
| Lesson for businesses | Hold independent backups, test recovery and do not treat provider redundancy as a continuity plan |
For related coverage, see our reports on the original London outage and single–region risk, the Azure ExpressRoute and VPN outage, UK data centre opposition and cloud capacity, the ConnectWise cloud backup breach and LINX LON2 and network resilience.
Keep an independent copy of what matters
We set up hybrid cloud backup for UK businesses, holding your data outside your primary provider, and test restores regularly — so an outage at one data centre never leaves you without your files, email or systems.
Talk to us about Hybrid Cloud BackupFrequently asked questions
Test your recovery before you need it
Our team reviews your cloud dependencies, puts independent backups in place and runs regular restore tests, so you know exactly how long recovery takes — and that it works.
Talk to us about Hybrid Cloud BackupGoogle’s generators were there, fuelled and ready. They simply never got the message. For every organisation, the takeaway is the same: redundancy you have not tested is a hope, not a plan.
Cloudswitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
