Google Cloud outage hits London region, and what UAE businesses should actually do about it

Google Cloud suffered an outage in its London region on 20 October 2026, taking banking apps, retail sites and delivery services offline across the United Kingdom, and the question most UAE business owners asked was the obvious one, does this affect us. The short answer is that no UAE bank or government platform has been confirmed as affected. The longer answer is more uncomfortable, because a surprising number of UAE business websites are hosted in exactly the region that went down, and most of their owners do not know it.

As at 15:58 UAE time on 20 October 2026, Google had mitigated the underlying fault and was recovering services, with the incident still open on its status page.

What happened in the Google Cloud London outage

The Google Cloud outage began at 10:08 UAE time on Tuesday 20 October 2026, which Google records as 23:08 Pacific on 19 October. Google's own incident page is the only authoritative account of the cause, and its wording is short.

Google stated that a power event caused an outage within the europe-west2-b zone, and that the power event had been mitigated. In a later update it said it was seeing recovery of services, was prioritising existing workloads, warned that customers might not yet be able to create new workloads, and gave a tentative full recovery time for existing workloads of 17:00 UAE time the same day.

Three details in that matter more than the headline.

• It was one zone, not the whole region. The London region, europe-west2, has three zones, a, b and c. The failure was in zone b. Google described the wider region as seeing increased errors and intermittent network issues rather than being down.
• Thirty eight products were listed as impacted. Compute Engine, Cloud SQL, Cloud Storage, Kubernetes Engine, Cloud Run, App Engine, BigQuery, Load Balancing, Pub/Sub, Spanner, Firestore, the Memorystore family, VPC and Private Service Connect among them. In other words, the layer almost everything else is built on.
• The only workaround Google offered was to move. Its advice was that affected customers could try to migrate the impacted workload to another zone or region where feasible. That is a meaningful sentence, because for most businesses it is not feasible, and that is the real lesson of the day.

A power event is a blunt description, and it is all Google has said so far. The confirmed root cause will arrive in a post incident report, usually within a week or two, and until then anything more specific is speculation.

Which services and companies were affected

The services affected were mostly British consumer brands, which is why the story travelled. Revolut publicly confirmed a service disruption, and Reuters linked it to the Google Cloud incident through an unnamed source. Beyond that, user reports spiked on Downdetector for a long list of names.

One caution worth stating clearly. Downdetector measures how many people are reporting a problem, not what caused it, and it says so itself. Only Google has confirmed a fault in its own platform. Every other name on that list is a company whose users reported problems during the same window, and in most cases nobody has confirmed the link. A responsible reading is that a major cloud zone failed and a lot of services that depend on that zone had a bad morning.

The two names on that list most relevant to a UAE business are the least discussed ones. Cloudflare and SiteGround are not consumer brands, they are infrastructure that thousands of ordinary business websites sit behind, including many in Dubai.

Was the UAE affected by the Google Cloud outage

No UAE bank, government platform or major local service has been confirmed as affected, and that is the accurate position rather than a reassuring one. UAE users did report difficulty with international sites and apps that depend on the London infrastructure, and Google reported no widespread problem with Search or Gmail.

There is a fact underneath this that very few UAE businesses know. Google Cloud has no region in the United Arab Emirates. Its Middle East regions are me-central1 in Doha, me-central2 in Dammam and me-west1 in Tel Aviv. So a UAE company on Google Cloud is hosted somewhere else by definition, and for a large number of them that somewhere is London, because europe-west2 has long been the default pick for anyone wanting an English language region with low latency to both Europe and the Gulf.

That is before you count the businesses hosted in London without using Google Cloud at all. The UAE SME hosting market is full of UK and European resellers, and a British data centre is routinely sold here as a quality signal. If your hosting invoice says London, Slough, Manchester or simply United Kingdom, the outage was not foreign news.

Why a London outage can still take a Dubai website offline

A Dubai website can go down in a London outage even when it is hosted in Dubai, and this is the part most owners have never thought through. A modern website is not one server, it is a dozen external dependencies loaded at the moment a visitor arrives, and every one of them is somebody else's uptime.

None of those live on your server. Each one is a company whose status page you have never read. The practical consequence is that asking which region your site is in answers only the first of ten questions, and the one that fails is rarely the one you were worried about.

This is a pattern now, not an incident

The pattern matters more than this particular outage, and the dates make the point better than any argument. Exactly one year ago to the day, on 20 October 2025, Amazon Web Services suffered a long outage in us-east-1 caused by a race condition in DynamoDB's DNS, which cascaded into well over a hundred of its own services because so many of them depend on DynamoDB.

That was not an isolated year.

• 12 June 2025, Google Cloud. A faulty automated update to the quota check system propagated globally and broke external API requests across dozens of services.
• 20 October 2025, Amazon Web Services. A DNS race condition in DynamoDB in us-east-1, with impact across a very large number of dependent services.
• 29 October 2025, Microsoft Azure. Customer configuration changes generated incompatible metadata in the content delivery network, which reached most edge sites before the protection system halted further changes.
• 18 November 2025, Cloudflare. A database permission change produced an oversized file that crashed the bot management system, and the change propagated across the global network, making thousands of websites unreachable.
• 20 October 2026, Google Cloud. A power event in one London zone, with thirty eight products listed as impacted.

Read as a list, two conclusions follow, and they point in opposite directions from the usual advice.

The first is that switching provider is not a strategy. All three hyperscalers have had a bad day inside eighteen months, and so has the largest independent network layer. Anyone telling you their platform does not go down is selling, and the honest version of that conversation is about how quickly you recover rather than whether you are ever affected.

The second is that the failure mode is almost never the one in the brochure. A power event, a DNS race condition, a permissions change producing an oversized file, bad configuration metadata. None of these are the dramatic scenarios redundancy is usually sold against, and most of them defeated systems that were already redundant, because the fault propagated through the thing that was supposed to provide the redundancy.

What actually breaks when a cloud zone fails

What breaks in practice is not usually the website, and this is worth understanding before deciding what to spend money on. In the outages we have handled for clients, the damage ranked in roughly this order.

1. Forms and enquiries stop arriving, silently. The page still loads, the form still submits, the confirmation still appears, and nothing reaches the inbox. This is the single most expensive failure and the hardest to notice, because there is no error for anyone to report.
2. Checkout and payment fails at the last step. Customers who were ready to buy leave, and almost none of them tell you or come back.
3. Nobody knows what to tell customers. The phone rings, support has no information, and the company says nothing publicly for two hours, which does more reputational damage than the outage.
4. Staff lose access to internal systems. The site being down is often the least of it when the admin, the CRM or the ticketing system is in the same place.
5. The site itself is unreachable. Genuinely damaging, but visible, understood and usually forgiven.
6. Recovery takes longer than the outage. Caches, queues, stuck jobs, duplicated orders and half processed payments all need sorting after the provider says resolved.

Notice that the first four are organisational rather than technical. A business that has decided in advance who posts what, where, and who checks whether forms are delivering comes out of an outage in far better shape than one with a more expensive hosting arrangement and no plan.

Ten checks to run on your own website today

These checks are worth running today while the subject is in front of you, and none of them needs a developer or a budget. Nine of the ten can be done by whoever handles your website in under an hour.

1. Find out where your website is hosted. The provider and the region, not just the company you pay. Ask your agency or your host directly and get the answer in writing, because "the cloud" is not an answer.
2. Find out where your database is. On many setups it is a separate managed service in a different place from the web server, and it is more often the thing that fails.
3. Find out who runs your DNS. Usually your registrar, your host or Cloudflare. If DNS fails, nothing else you have done matters, so this is the dependency to know about.
4. Find out where your email is. If your website and your email are with the same provider in the same region, one incident takes away both the site and the way you would tell anyone about it.
5. Submit your own enquiry form. From a phone, on mobile data, to an address outside your company, and confirm it arrives. Then do it monthly. This one test finds more lost revenue than any audit.
6. Prove you have a backup, by restoring one. A backup nobody has ever restored is a belief, not a backup. Ask for a restore into a staging environment and watch it work.
7. Check you would even know. If your site went down at two in the morning, who gets told. If the answer is a customer, you have no monitoring.
8. List your third party embeds. Chat, booking, maps, reviews, fonts, analytics, payment. For each one, decide whether the page should still work without it, then make sure it does.
9. Write the holding message now. Two sentences for the website, one for social, one for the phone script, saved somewhere you can reach when your own systems are down. Nobody writes well during an outage.
10. Know who to call. One named person with access who answers the phone, rather than a support queue and a hope. If you cannot name them, that is the gap to fix first.

What a UAE business should do instead of going multi region

Most UAE businesses should not go multi region, and we would rather say that than sell it. Running a genuinely redundant setup across two regions means duplicated infrastructure, replicated data, traffic steering, and a team able to test failover regularly, and the cost is not only the hosting. Done badly it adds failure modes rather than removing them, which is how companies end up less reliable after spending more.

There is a sensible middle, and it is where almost every business of under a few hundred staff belongs.

• Know your dependencies and write them down. One page listing provider, region and status page URL for hosting, database, DNS, CDN, email, payments and every embed. This costs nothing and is the single highest value thing on the list.
• Host near your customers. If your market is the UAE and the Gulf, there is no good reason for your site to be in London. Several providers have UAE and Gulf regions, and the latency improvement is a bonus on top of the geopolitical and regulatory simplicity.
• Separate what must not fail together. Put your email and your website with different providers. Keep backups with a third. Avoid the arrangement where one incident removes the service, the backup and the ability to communicate.
• Make the site degrade rather than break. A page that loads and works without its chat widget, its map and its review feed is a design decision made once, and it converts a total failure into a cosmetic one.
• Monitor from outside, and monitor the form. Uptime checks from a third party network, plus a synthetic submission that proves the enquiry path still delivers. Monitoring that runs on the same infrastructure as the site tells you nothing when that infrastructure fails.
• Keep backups off the platform. Daily, retained for a sensible period, held somewhere other than the provider hosting the site, and restored to staging on a schedule so you know it works.
• Have a static fallback page ready. A single lightweight page with your phone number, address, hours and a short message, hosted somewhere unrelated, that DNS can be pointed at. This is a modest piece of work that buys back most of the reputational damage.
• Write the runbook before you need it. Who declares an incident, who posts, what gets said, who checks forms afterwards, and what is verified before you call it over.

That is a realistic programme for a UAE SME. It is mostly process rather than infrastructure, the cost is modest, and it addresses the failures that actually happen rather than the ones that sound impressive.

How Tomsher handles hosting, uptime and recovery

Hosting, uptime and recovery are part of our maintenance work rather than an upsell after an incident, because the time to find out your backup does not restore is not the morning your region loses power. Our website maintenance and AMC service is where this sits, and our note on why a website AMC matters sets out the scope.

• A documented dependency map. Provider, region and status page for every component of the site, kept current rather than written once.
• External uptime monitoring with form delivery checks. So the first person to know is us, not your customer.
• Backups that are restored on a schedule. Held off the hosting platform, and tested rather than assumed.
• Graceful degradation built in. Third party embeds loaded so that the page still works when they do not.
• Hosting advice based on where your customers are. Including moving a site out of a region that no longer makes sense for a UAE business, handled through website migration services.
• A named person who answers. Fully in house, so during an incident you reach someone who knows your setup rather than a queue.

Tomsher is an experienced, reliable and fully in house web design and development company in Dubai, operating since 2011, with more than 15 years of delivery experience and a 4.9 out of 5 rating from 201 Google reviews. Design, development, hosting, maintenance and SEO sit in one office, which is why an uptime problem and a performance problem get handled in the same conversation.

Google Cloud outage FAQs

Common questions about the Google Cloud London outage and what it means for a business in the UAE.

What caused the Google Cloud outage on 20 October 2026?

Google has said only that a power event caused an outage within its europe-west2-b zone in the London region, and that the power event was mitigated. That is the extent of the confirmed cause at the time of writing. The incident began at 10:08 UAE time, Google listed thirty eight affected products, and it gave a tentative full recovery time for existing workloads of 17:00 UAE time the same day. A detailed root cause normally follows in a post incident report within a week or two, and anything more specific before then is speculation.

Was the UAE affected by the Google Cloud outage?

No UAE bank, government platform or major local service has been confirmed as affected. UAE users did report problems with international sites and apps that depend on the affected London infrastructure, and Google reported no widespread issue with Search or Gmail. The more important point for a UAE business is that Google Cloud has no UAE region, its nearest Middle East regions being Doha, Dammam and Tel Aviv, so a UAE company on Google Cloud is hosted elsewhere by definition, and London is one of the most commonly chosen regions.

How do I find out whether my website was affected?

Ask your host or agency which provider and which region your website, your database and your email are in, and get it in writing. Then check that provider's status page for the window in question. If your site was unreachable or erroring this morning and your hosting is in the United Kingdom, the two are probably related. The quicker diagnostic is simply to submit your own enquiry form from a phone and see whether it arrives, because a form that stopped delivering during an incident often stays broken afterwards.

Should I move my website out of Google Cloud?

Not because of one outage. All three major cloud platforms and the largest independent network provider have had significant outages within the last eighteen months, so switching on the basis of the most recent incident simply moves you to whoever is next. There is a better reason to move, which is proximity. If your customers are in the UAE and the Gulf and your site is in London, you are accepting worse latency and a dependency on an unrelated market's infrastructure for no benefit. That is a migration worth doing on its merits rather than in reaction to a bad morning.

Does a UAE business need multi region hosting?

Almost certainly not. Genuine multi region redundancy means duplicated infrastructure, replicated data, traffic steering and regular failover testing, and done without the discipline to test it, it adds failure modes instead of removing them. For nearly every business under a few hundred staff the sensible programme is different: know and document every dependency, host near your customers, keep email and backups away from the website's provider, monitor from outside including whether forms deliver, make the site work without its third party embeds, and have a static fallback page and a written runbook ready.

My website is hosted in Dubai. Am I safe?

Safer, but not immune, because a website is not one server. Your DNS provider, your CDN or proxy, your payment gateway, your transactional email service, your booking widget, your chat tool, your hosted fonts and your analytics are all other people's infrastructure loaded when a visitor arrives, and any of them can be in a region that fails. During this incident two of the Names with a spike in user reports were Cloudflare and SiteGround, neither of which is a consumer brand but both of which sit in front of a great many ordinary business websites, including in the UAE.

What is the most damaging thing that happens during an outage?

Enquiry forms that stop delivering without any visible sign. The page loads, the form submits, the confirmation message appears, and nothing arrives in the inbox, so there is no error for anyone to report and the loss continues after the provider has declared the incident resolved. In our experience that costs more than the downtime itself, followed by failed checkouts and then by having nothing to tell customers for the first two hours. The site being unreachable is damaging but visible, understood and usually forgiven.

How often do outages like this happen?

More often than most owners assume, and with causes nobody plans for. In the eighteen months before this incident there was a Google Cloud global problem in June 2025 from a faulty automated quota system update, the Amazon Web Services us-east-1 outage on 20 October 2025 from a DNS race condition in DynamoDB, a Microsoft Azure content delivery network incident on 29 October 2025 from bad configuration metadata reaching most edge sites, and a Cloudflare outage on 18 November 2025 from a database permission change producing an oversized file. The lesson is about recovery speed, not provider choice.

What should we post while our website is down?

Something, quickly, and from a channel that is not affected. Two sentences on social media saying what is not working, that you are aware of it, how customers can reach you in the meantime, and when you will next update. Then update when you said you would, even if there is no news. The reputational damage in an outage comes mostly from silence rather than downtime, so the practical step is to write those sentences now, while nothing is broken, and save them somewhere you can reach when your own systems are not available.

Can Tomsher review our hosting and recovery setup?

Yes, and it is a short piece of work rather than a project. We map every dependency your site relies on with its provider, region and status page, test whether your enquiry forms actually deliver, check whether your backup restores rather than merely exists, review how your site behaves when third party embeds fail, and tell you which single change would most reduce your exposure. If the setup is sound we will say so. Where a move makes sense, we handle it through our website migration work with redirects mapped before anything changes.