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
Rather than checking: these are
feeds. Put one in a feed reader
or in Slack and you will hear once when a cloud breaks and once when it
clears. No sign-up and no email address — you are not on a list,
because there is no list.
Latest update, in the vendor’s wordsWe are providing an update on the disruption affecting the Middle East (UAE) (me-central-1) Region. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in the mec1-az2 Availability Zone. We continue to work on recovering regional resources, as well as zonal resources hosted in the other affected Availability Zones (mec1-az1 and mec1-az3). Since the disruption began in March, most customers have been able to re-establish their operations in other Regions by restoring backups or copying data that remained accessible. AWS Support remains available to help customers who need assistance moving their applications to alternate Regions. We remain committed to supporting our customers in the UAE. We are working on replacing the affected infrastructure and will provide an update on the restoration of our services in the
Latest update, in the vendor’s wordsWe are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed a
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
2 of 90
Google Cloud
5 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 8 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.
GitHub
Not a cloud, and not counted with the three above. It is here because GitHub Pages and Actions are what build and serve this site — when they break, this page breaks with them. Status comes from GitHub’s own Statuspage API.
All Systems Operationalas GitHub reported it, 2026-10-25 11:29
Component health and incidents come from GitHub’s Statuspage API. The uptime percentages shown on githubstatus.com are not in that API and are not reproduced here — a figure computed from incident durations would not match the one GitHub publishes. githubstatus.com →
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.
930 outages recorded across the three clouds, the same set the timeline above is drawn from. 77 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.
Counted, not claimed: 17 refreshes in the last 24 hours (fewer than the hourly schedule intends), 103 in the last 7 days. Most recent: 25 Oct, 13:19 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.