Live incidents across AWS, Azure and Google Cloud, read from each
vendor’s own status feed. Nothing here is summarised or inferred —
the wording is theirs.
Last checked just now · refresh is scheduled hourly and can run late, so this timestamp is the one to trust
AWS
2 incidents
as reported by the vendor
read just now
Azure
No active incidents
vendor reports none
read just now
Google Cloud
No active incidents
vendor reports none
read just now
AWSOngoing
Increased Error Rates
Service
Multiple services
Region
UAE me-central-1
Announced
01 Mar 2026 12:51 UTC
Open for
193 days
Reach
regional · UAE
Latest update, in the vendor’s wordsWe are providing an update on the ongoing service disruption. The Middle East (UAE) Region (ME-CENTRAL-1) has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications. While some workloads continue to function normally, we strongly recommend customers migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.
Latest update, in the vendor’s wordsWe are providing an update on the ongoing service disruption. The Middle East (Bahrain) Region (ME-SOUTH-1) has suffered damage due to the conflict in the Middle East and is currently unavailable. Customers should recover their resources in other Regions from remote backups. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.
One cell per day. A cell is marked only where a vendor published an
incident that was open on that day — an unmarked cell means nothing was
reported, not that anything was verified healthy.
AWS
90 of 90
Azure
1 of 90
Google Cloud
19 of 90
incident beganstill opennothing reportednot recordeddays are UTC
Days here are counted in UTC, while the vendors’ own dashboards show your local time — so an incident late in your evening can sit on the next day here than on theirs. Open a cell and it prints both. A grey cell is a gap in the record, not a good day — it means the vendor’s own history does not reach that far back, not that nothing happened. Each record reaches to: AWS to 2025-09-08, Azure to 2021-07-23, Google Cloud to 2021-09-13.
Where the clouds are, and where they break
What the vendors do and don’t tell you
The three publish very different amounts, and that difference is
itself worth knowing when you decide how far to trust a status page.
Why the timings below are Google’s only.
Google publishes when an incident began and, separately, when it first
said something publicly, so the gap between the two is a real number. AWS’s
status data carries no start time distinct from its first announcement, making
that gap structurally zero; Azure’s feed carries no start time at all.
Ranking all three would put AWS first for disclosing less, so only the cloud
that supplies the inputs is measured.
For what it is worth, across 6 recorded Google incidents the median gap between an incident starting and the first public word was 209 minutes, and the widest was 5 days. Too few to predict anything — shown because the numbers exist for Google and cannot for the other two.
Past outages
Every outage the three clouds have recorded, by year and by
cloud. Open one for what the vendor said about it and a link to their own
page for it. Where they published a full incident report, you get the whole
thing.
922 outages recorded across the three clouds, the same set the timeline above is drawn from. 73 of them have a full incident report from the vendor; the rest carry what the vendor recorded — what it was, when, and a link to their page for it. Nothing is left out for being minor. How far back each goes is their choice, not a filter here: AWS back to 2011; Azure back to 2021; Google Cloud back to 2021. A missing year means nothing was published for it — and 4 AWS summaries state a month and day with no year anywhere in the text, so they sit under Undated rather than being guessed into one.
Counted, not claimed: 84 refreshes in the last 24 hours (on schedule), 85 in the last 7 days. Most recent: 10 Sep, 09:36 UTC. Every refresh is a commit, so the record is public and dated.
No ETA appears anywhere on this page. None of the three publishes one
as structured data, and lifting “we expect recovery shortly” out of an
update would manufacture a commitment the vendor never made.