A failure at one of Google’s data centers was enough to disrupt payments, banking apps, and online services. If something similar happened tomorrow to your business’s service provider, how long could you keep working?
On October 20, 2026, issues with Google Cloud’s infrastructure in London affected services that relied on it. Reports of the disruption included Revolut, Lloyds, and Halifax, while issues were also reported with other digital services in the United Kingdom.
What Actually Happened
Google itself logged the outage in the europe-west2 region on its official service status dashboard, with a particular impact on the europe-west2-b zone. The company attributed the incident to a power supply issue (“power event”).
According to the official record, the incident lasted 7 hours and 52 minutes. Various infrastructure products were affected, including computing, database, and networking services. Google announced that service had been restored and noted that it would publish an analysis following an internal investigation.
“Google didn’t go down completely.” The incident affected a specific region of Google Cloud. It does not amount to a general outage of the search engine or Gmail, nor does it prove that all systems using Google Cloud experienced a problem.
Why were different companies affected at the same time?
An app may appear to run independently on your phone, but behind the scenes it may rely on computers, databases, networks, or authentication services hosted on a shared infrastructure. When that infrastructure malfunctions, the consequences can affect many independent businesses.
This is called dependence on a single point of failure. It doesn’t mean that the cloud is inherently unreliable. It means that resilience doesn’t automatically follow simply because “we have everything in the cloud.”
What does this mean for a Greek e-shop?
Think of a small online store. The website might be functioning normally, but the payment system might not be working. Or an order might be completed, but the update doesn’t reach the management system. Or you might have your files available, but be unable to log into the account where you manage them.
These are illustrative risk scenarios, not a claim that they occurred at specific Greek stores on October 20.
The question isn’t just whether a backup exists. It’s also how quickly operations can resume when a critical service is unresponsive.
Five checks worth performing before a problem arises
- Document the dependencies. Hosting, email, DNS, payments, file storage, automations, and vendors all require a simple list: which system relies on which.
- Test your backups in practice. A backup that hasn’t been tested with a restore isn’t enough to guarantee recovery.
- Consider a fallback plan. How will you serve customers if the website or online payments are temporarily down? Who will provide updates, and through which channel?
- Discuss availability with your provider. Hosting across multiple zones or regions can mitigate certain risks, but it requires proper planning and incurs costs. It does not protect every architecture from every failure.
- Designate a person in charge and establish a procedure. Who is the first to notice the problem, who contacts support, and who decides when to activate a contingency plan?
Backup and business continuity are not the same thing
Backups help with data recovery. A business continuity plan describes how the business continues to serve customers while a service is unavailable. Both are necessary, but they address different problems.
For a small business, the first step isn’t necessarily to pay for a complex, multi-regional infrastructure. It is to know what will stop working, what level of loss it can withstand, and which measures offer real value for a business of its size.
The question worth asking today
“If a key digital service were to go down for eight hours tomorrow, do we know what to do?”
If the answer is “no,” there’s no need to panic. What’s needed is documentation, prioritization, and a proven response plan. At BEEGITAL, we treat the stability of a website or e-shop as part of the business’s day-to-day operations—not as a technical detail we only remember after a failure.