Outage Status Pages
How Do You Read an Outage Status Page?
Short answer
You read an outage status page by looking at its exact words, not just whether it admits a problem. During Google Cloud's London outage on October 20, 2026, the page used phrases like "completed, tentatively" and "mitigated for most of the customers." Each one promised less than it first appears to, and that gap is what to watch.
Key takeaways
- Google's status page title named the whole europe-west2 (London) region, while The Register reported that the failing zone was europe-west2-b, one of three in that region.
- The Register reported that the trouble began at 0608 UTC on October 20, 2026. Google's status page showed the incident as closed after 7 hours and 52 minutes.
- A status update that says recovery should be complete "tentatively" by a set time is a target, not a result.
- "Mitigated for most of the customers" is not the same as fixed for everyone.
- Four parts of a status page are worth watching: the incident title, the status label, the latest update text, and the list of affected products.
Google's cloud status page gave the October 20, 2026 incident a title that sounded huge: "Multiple services are experiencing issues in the europe-west2 region." That region is London. The cause, according to The Register, was smaller and more specific: one of the region's three availability zones.
That mismatch between a big title and a narrower cause is the kind of detail a careful reader catches. The Register reported that Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix, and Revolut were among the customers affected, so plenty of people had a reason to read closely.
What actually happened on October 20?
A power event in one zone of Google's London cloud region caused services to fail, starting at 0608 UTC. Per the update note in The Register's report, the status page said most customers were back to normal service at 14:03 UTC.
The Register said the zone was europe-west2-b, one of three availability zones in the London region. Google's status page listed AlloyDB for PostgreSQL, Apigee, BigQuery Data Transfer Service, and 35 more products as affected. It showed the incident as closed after 7 hours and 52 minutes.
Google gave no further detail about the power event, The Register noted, and said it would publish an analysis after its internal investigation. One academic, Dr Amro Al-Said Ahmad of Keele University, estimated that 38 services were down, though the article does not explain how he reached that number.
What phrases did the status page use, and what did they mean?
Five phrases stand out, and each one says less than it first seems to. The table pairs the wording, as reported by The Register and shown on Google's status page, with a plain reading. The Register's report does not give a full timeline, so the rows are not in clock order.
| Wording | What a careful reader hears |
|---|---|
| "Multiple services are experiencing issues in the europe-west2 region." (incident title) | Something is wrong across London. The title gives no cause and does not say how many zones are involved. |
| Services were recovering, existing workloads were prioritized, and new workload creation might be unavailable (The Register's summary). | Things already running were the priority. Starting something new might not work. |
| At 1158 UTC: full recovery expected to be "completed, tentatively" by 1300 UTC, with another update then. | A forecast, not a result. |
| Impacted products "mitigated for most of the customers," with a "very small number" still affected. | Most is not all. If you are in the small group, check your own systems. |
| Incident marked closed, with an analysis promised after the internal investigation. | The incident is over on the page. The explanation is still to come. |
Is a target time the same as a fix?
No. A target is a promise about the future, and only a later update tells you whether it held. At 1158 UTC, Google said full recovery was expected to be "completed, tentatively" by 1300 UTC.
The Register did not say whether that 1300 UTC update arrived on time. The milestone it reported at 14:03 UTC said most customers were back to normal. If you were planning your afternoon around 1300, that gap was the part that mattered.
Which parts of a status page are worth watching?
Four of them. Google's incident page showed a title, a status, a last update time, a duration, a location, and a list of impacted products, and these four do the most work.
- The incident title.Here it was the "Multiple services are experiencing issues" line, which named a whole region.
- The status label.The page showed this incident as closed at the end.
- The latest update text.Words like "tentatively" and "mitigated" are where the meaning sits.
- The affected product list.It started with AlloyDB for PostgreSQL, Apigee, and BigQuery Data Transfer Service, then ran to 35 more. Find the products you rely on.
What should a business do before the next outage?
Make a short list of the services you cannot work without, and find the status page for each one before you need it. Do that on a calm day, not in the middle of an incident.
Then decide which words on each page mean "act" for you. For one team that might be the status label changing to closed. For another it might be the wording "mitigated for most." Write it down, so whoever is on call is not guessing at 6 a.m.
Can a page monitor watch a status page for you?
Yes. Alertbase can watch a status page, or just one element on it, like the incident title or the status label. You describe what you care about in plain language, such as "Tell me when this incident is marked closed." Alerts can go by email, by mobile push in the Android app, or to Slack, Discord, Microsoft Teams, Telegram, or a webhook.
Each alert can include a short summary of what changed and before and after screenshots with highlighted areas, when available. Checks run on a schedule that goes from daily down to every few minutes on higher plans, so no tool can promise to catch every update the moment it appears. It can spare you the refresh button.
Questions people ask
What caused the Google Cloud outage on October 20, 2026?
Google's status page pointed to a power event, according to The Register. The problem began at 0608 UTC in the europe-west2-b zone, one of three availability zones in Google's London region. Google gave no further detail and said it would publish an analysis after its internal investigation.
How long did the Google Cloud outage last?
Google's status page showed the incident as closed after 7 hours and 52 minutes. The Register reported that the status page said most customers were back to normal at 14:03 UTC. An update reported during the incident said a very small number of customers were still affected.
Which companies were affected by the Google Cloud outage?
The Register named Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix, and Revolut. Google's status page listed AlloyDB for PostgreSQL, Apigee, BigQuery Data Transfer Service, and 35 more affected products. One academic estimated that 38 services were down.
How do I know when a status page problem is really over?
Read the status label and the latest update text together. A closed label is stronger than wording that says most customers are back. In this incident, an update said a very small number of customers were still affected, so check your own systems too.
How can I get an alert when a status page changes?
Watch the incident title and status label with a page monitor that sends an alert when that part of the page changes. A plain language request like "Tell me when this incident is marked closed" can describe what you care about. Alerts can go to email, Slack, or other channels.
Sources
- Google Cloud says a 'power event' caused today's outage, The Register
- Google Cloud Service Health, Google Cloud
Ready to set up your first monitor?
Start a 14-day free trial and set up your first monitor without a credit card.