Cloud region outages and the customer journeys they stop

On Tuesday 20 October 2026, Google reported disruption in its London cloud region, europe-west2, starting at 10:08 UAE time. Google's update described "intermittent network failures and elevated errors across several services". Gulf News reported the same day that banking and online services in the UK were disrupted.

None of the reporting describes an attack. Availability can fail through dependencies, and the customer sees the same failed login or payment whatever the cause. This article looks at what was reported, what it means for banks and operators in the Gulf and Southeast Asia, and how to map and test customer journeys against the regions and providers they rely on.

What was reported

According to Gulf News:

• Revolut customers reported problems with card payments, transfers, ATM withdrawals and account access.
• Customers of Lloyds, Halifax and HSBC reported problems accessing online banking.
• Rightmove, DPD and ING Germany were also reported as affected.
• Reuters, citing an unnamed source, linked the bank disruption to the Google Cloud outage. It was unclear whether all the reported problems were connected.
• At the time of the report, Google had not identified a cause or given a definite restoration time.

We are not drawing conclusions about how any of these organisations built their services. Outages in large cloud regions affect well-run firms, and the public reporting doesn't say enough to judge anyone's design.

Was the UAE affected?

Gulf News found no confirmed reports linking the outage to UAE banks, government platforms or major local services. It noted that UAE users might have difficulty with international services that rely on London infrastructure.

That last point applies well beyond the UAE. A bank in Riyadh, Doha, Kuala Lumpur or Jakarta may host its core systems locally and still depend on a SaaS tool, an identity provider, a payment processor or a monitoring service that runs in a region on another continent.

Concentration and third-party dependency

Two kinds of risk show up in an event like this.

Concentration risk is the exposure that builds when many services, or many firms, rely on the same provider or the same region. One regional failure then reaches many places at once.

Third-party dependency is the chain behind each service. Your own systems may be spread across zones, but a single upstream provider in your login or payment path can still take that customer journey down.

Neither risk is visible from an architecture diagram that stops at your own perimeter. You only see it by tracing each customer journey all the way through.

Mapping customer journeys to regions and providers

A practical way to start is to pick the customer journeys that matter most to your customers and your regulator. For a bank, that usually includes login, balance check, domestic transfer, card authorisation and instant payments on rails such as Aani (UAE), sarie (Saudi Arabia) or DuitNow (Malaysia). For a telco, it might be top-up, SIM activation and customer self-service.

For each one, record:

• Every system and service the customer journey touches, in order.
• Where each one runs: provider, region and availability zone, where known.
• Which ones are run by third parties, and which third parties they depend on in turn.
• What the customer sees if each component slows down or stops.
• Who owns the response, internally and at the provider, with current contact details.

Then ask the scenario question directly: if one region degrades for a few hours, which customer journeys stop, which slow down, and which carry on? You want that answer from the map, well before anyone is on an incident bridge.

What UAE regulation says

Gulf News reported on 15 September 2026 that the Central Bank of the UAE's new Operational Risk Management Regulation requires banks to:

• Identify critical operations and map their interdependencies.
• Manage third-party risk, especially for providers supporting critical operations.
• Test business continuity and disaster recovery plans under severe but plausible scenarios.

A cloud region outage fits that last description well. Other regulators in the GCC also expect banks to identify critical operations and manage third-party risk, each through its own framework. The customer journey map above is the kind of evidence those expectations point towards.

Testing customer journeys under stress

A map tells you what should happen. A test tells you what does. Useful tests for dependency risk include:

• Failover exercises that move a customer journey off a region or provider and measure how long it takes and what breaks.
• Load and stress tests on each critical customer journey, so you know where it degrades before a real event pushes it there.
• Checks that timeouts, retries and fallback screens behave sensibly when an upstream service is slow, as well as when it is fully down.
• Communication drills: who calls the provider, who updates customers, and who informs the regulator.

One set of evidence for two problems

DDoS attacks and provider outages are different events with different causes. They hit the same customer journeys, though, and the questions are the same: does login still work, does the payment go through, and how fast does the service recover? Journey-level evidence, gathered under realistic stress, answers both. It also gives operational risk and compliance teams something concrete to show when they are asked how critical operations hold up.

If you want to see how your critical customer journeys behave under stress, get in touch at https://obsidio.me/contact