Cloud Outage Tracker 2026
Last updated: August 9, 2026, 16:00 UTC| Update cadence: Weekly (every Sunday) | Maintained by: Axis Intelligence Research & James Porter
Nine verified incidents in the log. Six carry a computed Diagnostic Lag Ratio™. Two carry an open verification flag, stated openly below.
Quick Answer: What Is the Cloud Outage Tracker?
The Axis Cloud Outage Tracker logs every major public-cloud and core-internet-infrastructure outage for which the operator has published a post-incident document. Nine incidents are currently logged, spanning AWS, Microsoft Azure, Google Cloud, Cloudflare, and DENIC. Across the six incidents with published diagnostic timestamps, Axis Intelligence Research finds a mean Diagnostic Lag Ratio™ of 0.27 — meaning roughly a quarter of total customer impact time was spent before the operator knew what had broken.
Key Findings
According to Axis Intelligence Research, the mean Diagnostic Lag Ratio™ across six 2025–2026 incidents with published root-cause timestamps is 0.27, with a median of 0.10 (as of August 9, 2026).
Axis Intelligence Research finds that software- and configuration-caused outages carry a mean Diagnostic Lag Ratio™ of 0.41, while power and cooling failures carry 0.00 — physical failures are recovery-bound, software failures are diagnosis-bound.
Amazon Web Services has published no Post-Event Summary for any incident occurring in 2026; its most recent entry remains the DynamoDB DNS disruption of October 19, 2025, per the AWS Post-Event Summaries archive retrieved August 9, 2026.
Microsoft’s Post Incident Review for the West US network outage of July 23, 2026 records that engineers correlated the routing anomaly to the triggering break-fix activity at 17:19 UTC, 2 hours and 35 minutes after impact began at 14:44 UTC.
Google’s incident report for europe-west4-a states that data hall temperatures reached 44°C on July 15, 2026 after a 3-millisecond voltage drop cascaded into a cooling failure, producing a total service interruption of 14 hours and 55 minutes.
How We Curate This List
The inclusion rules are the methodology. They are stated here so that anyone can reproduce this dataset, disagree with it, or extend it.
What qualifies as an entry. An incident enters the log when three conditions are met at once. The operator has published a written incident document under its own name — a post-event summary, a post-incident review, a status-page incident report, or an engineering blog postmortem. That document states, at minimum, a start time and an end time. And the impact reached customers, not just internal systems.
What does not qualify. Degradations reported only by third-party monitors. Incidents known only through Downdetector report counts — those measure how many people complained, not how long a service was unavailable, and they are excluded from the dataset entirely even where widely quoted. Scheduled maintenance. Regional internet disruptions caused by government action or cable cuts, which belong in a different log. And any incident where the only available account is a news article: a secondary source can tell us an incident exists, but the figures come from the operator’s own document or the row does not ship.
Providers in scope. The four hyperscale and edge providers whose failures propagate outward — AWS, Microsoft Azure, Google Cloud, Cloudflare — plus registry-level DNS operators, because a top-level domain failure produces the same practical outcome as a provider outage for everyone downstream of it.
Tier definitions. Tier 1 is multi-region, global, or whole-zone-of-authority impact. Tier 2 is a single region. Tier 3 is a single availability zone or a single service within a region. Tier is assigned on blast radius, not on duration or press coverage — a fourteen-hour single-zone failure stays Tier 3.
Verification flags. Every row carries one. none means every recorded figure came from a document read during production. pending_primary means a figure is missing because the operator has not published it, or because the source document has not yet been read end to end; the row ships with the gap visible rather than filled from memory. source_inconsistency means the operator’s own document contradicts itself, and the note records which figure we took and why.
Times. All entries are normalised to UTC. Where an operator publishes in local or Pacific time, the conversion is noted in the row’s method_note.
The Diagnostic Lag Ratio™ (DLR™): How Much of an Outage Is Spent Not Knowing
This is the metric this tracker exists to publish. Duration alone is a bad comparator — a fourteen-hour outage caused by a burnt-out power feed and a five-hour outage caused by a bad API parameter are not the same kind of event, and averaging them tells you nothing about either.
Formula, version 1.0:
DLR = (minutes from customer impact start to operator's published
root-cause identification) ÷ (total customer impact minutes)
Both terms come from the operator’s own published timeline. Nothing is estimated. Where an operator publishes restoration milestones but no root-cause timestamp — DENIC’s final report is the example in this log — the ratio is left empty rather than inferred. A DLR near 0 means the operator knew immediately and spent the outage recovering. A DLR near 1 means the operator spent almost the entire outage looking in the wrong place.
Inaugural baseline, as of August 9, 2026. This is a baseline reading, not a trend. No prior history exists for this metric because no one has computed it before.
| Cohort | Incidents with computable DLR | Mean DLR™ | Median DLR™ |
|---|---|---|---|
| All incidents | 6 | 0.27 | 0.10 |
| Software, configuration, and change-management causes | 4 | 0.41 | 0.34 |
| Power and cooling causes | 2 | 0.00 | 0.00 |
Source: Axis Intelligence Research, computed from operator post-incident documents. Full inputs in the CSV below.
The split is the finding. When a chiller controller drops offline, the cause announces itself — Google’s engineers were alerted to the power loss at 16:30 US/Pacific on July 15, six minutes after the utility fault and before customers felt anything. Nothing was mysterious. The 895 minutes of impact were 895 minutes of physical restoration: rebooting hosts, validating storage nodes, waiting for a technician to reach a console server at 22:40.
Software is the opposite. Azure’s OpenAI Service incident on May 29 ran 446 minutes, and for 401 of them the investigation was pointed at the wrong component. Engineers disabled a suspected error-handling feature at 12:17 UTC; traffic in Australia East fell off naturally around the same time; service improved; the mitigation looked like it had worked. It hadn’t. The retry storm was still there, waiting for the upstream rollout to reach Sweden Central at 14:20 UTC, where the same defect hit a far larger traffic volume. A DLR of 0.90 is what a false-positive mitigation costs.
Stated limitations. DLR depends entirely on what operators choose to publish, which means it is measurable only for the incidents where a company was transparent enough to timestamp its own confusion — a selection bias that runs against the transparent. It says nothing about severity, customer count, or revenue impact. And “root-cause identification” is the operator’s own claim about when it understood the failure; Azure’s May 29 entry shows how a company can believe it has identified a cause and be wrong. The ratio is a measure of published diagnostic narrative, not of ground truth.
2026 Incidents (Reverse Chronological)
July 23, 2026 — Microsoft Azure, West US: a break-fix repair took out a whole datacenter’s egress
Between 14:44 and 19:41 UTC, traffic entering or leaving the West US region failed. Traffic that stayed inside the region was fine. Microsoft’s PIR (tracking ID ZJV6-SGG) attributes it to a defect in the blast-radius analysis system, which expanded an unplanned repair on one optical device to cover every optical device egressing a datacenter. The safety check ran and passed — it validated each device individually rather than the aggregate effect of isolating all of them at once, a case the system was never designed to receive.
Two things made this slow. Physical links and routing adjacencies kept looking healthy after the routes were withdrawn, so the failure presented as a WAN anomaly rather than a datacenter one. And the automated rollback depended on the same datacenter connectivity that had just been removed, so it retried, failed, and retried again until 16:58 UTC before escalating to a human. Correlation at 17:19, manual rollback at 17:45, connectivity restored at 18:26, all services clear at 19:41. DLR™ 0.52. Tier 2. Microsoft Post Incident Review, tracking ID ZJV6-SGG
July 15–16, 2026 — Google Cloud, europe-west4-a: three milliseconds of bad voltage, fifteen hours of recovery
A 3-millisecond voltage drop on the utility feed tripped the breakers on both the A and B power feeds at a Netherlands facility. Side B transferred to backup DRUPS cleanly. Side A’s DRUPS failed to take the load because of electrical component failures, which pushed three server rows onto feed B; two transferred, and Row 3 tripped an overload breaker and lost power entirely. Separately, the chiller controller dropped offline during the transient and never signalled the distribution pumps to restart. The redundant chiller was unavailable due to ongoing construction at the site.
Data hall temperatures hit 44°C at 18:29 US/Pacific. Google shut down every reachable machine. Google Cloud VMware Engine, Bare Metal Solution, and NetApp Volumes went down for a combined 14 hours and 55 minutes, affecting 24 private clouds across 20 distinct GCVE customers and 9 BMS customers. DLR™ 0.00 — nothing here was a mystery, and that is precisely why it took so long. Tier 3, single zone. Google Cloud Service Health incident report
May 29–30, 2026 — Microsoft Azure, West US 2: lightning, then a cooling lockout
Between 04:24 UTC on May 29 and 02:30 UTC on May 30 — 22 hours and 6 minutes — customers in West US 2 saw connectivity, availability, and service-management failures across two physical availability zones. A thunderstorm produced voltage sags rather than a clean power loss, which is the worse case: utility power stayed present but unstable, so some datacenters transferred to generators and others did not. Cooling components across multiple facilities independently entered a protective lockout state and would not return automatically.
Cooling was back within about two hours. Roughly 95% of virtual machines had recovered by 12:00 UTC. Storage validation, which Microsoft notes must run sequentially, stretched across roughly 14 hours, and Log Analytics and Application Insights needed another six hours after that to clear backlogs. DLR™ 0.00. Tier 2. Microsoft Post Incident Review, tracking ID GHRP-84G
May 29, 2026 — Microsoft Azure OpenAI Service: a retry storm from Microsoft’s own workload
An upstream change in an API layer used by Microsoft 365 altered how capacity-related failures surfaced. Conditions that previously returned in a form that did not trigger broad retries began returning as transient server errors instead. Multiple layers of the calling stack read those as retriable and retried immediately, without backoff or jitter. Microsoft records that a single failed request could produce up to 48 additional retry attempts.
The rollout hit Australia East first, exhausted resources in the inference routing layer, and appeared to be fixed by a mitigation that was actually a coincidence. When the rollout reached Sweden Central at 14:20 UTC, the same pattern returned at European traffic volume: out-of-memory crashes across multiple instances and degradation across the shared routing path. Microsoft’s own account notes that the affected internal workload was not subject to the rate-limiting and overload controls applied to external traffic. DLR™ 0.90 — the highest reading in this log. Tier 1, multi-region. Microsoft Post Incident Review, tracking ID LYXT-C1Z
May 5–6, 2026 — DENIC, .de: a key rollover took a top-level domain off the internet
From 21:57 CEST on May 5, DENIC published invalid DNSSEC signatures for the .de zone. Every validating resolver on the planet was then required by specification to return SERVFAIL. DENIC’s final report attributes it to an error in the software code of an in-house development, deployed as the third generation of the .de signing system in April 2026 after advance testing and an external audit.
The detail worth keeping is the one in DENIC’s report about NSEC3: because a TLD zone mostly returns delegation information, unverifiable signatures on NSEC3 records meant that even second-level domains not using DNSSEC at all became unresolvable. A correct zone began distribution at 00:08 and pre-outage status was restored by 01:15 — roughly three hours. Cloudflare’s account of the same event describes serving stale records to cushion the impact for 1.1.1.1 users. DLR™ not computable — DENIC published restoration milestones but no root-cause identification timestamp. Flagged pending_primary. Tier 1. DENIC final report
February 20, 2026 — Cloudflare: an empty query parameter deleted every BYOIP prefix
A cleanup sub-task, built as part of Cloudflare’s Code Orange: Fail Small work to replace manual prefix removals with automation, queried the Addressing API with pending_delete and no value. Go’s Query().Get() returns an empty string for that, the server interpreted it as a request for all BYOIP prefixes, and the task began deleting them along with their service bindings until an engineer noticed and killed it.
Cloudflare’s numbers: of 4,306 total BYOIP prefixes, 25% were withdrawn unintentionally; 1,100 prefixes out of 6,500 advertised to the sampled peer went dark between 17:56 and 18:46 UTC. Around 800 were restored by 20:20; roughly 300 could not be re-advertised from the dashboard because their service bindings had been deleted, and were restored manually at 23:03. Visitors to one.one.one.one saw 403 errors, though resolution over 1.1.1.1 itself was unaffected.
An editorial note on this row. Cloudflare’s post states the outage began at 17:48 UTC and lasted 6 hours 7 minutes; its own event table records impact starting at 17:56 and ending at 23:03, which is 5 hours 7 minutes. The two figures in the same document do not reconcile. Axis Intelligence Research records the timeline table (307 minutes) and flags the row source_inconsistency rather than picking the more dramatic number. DLR™ 0.16. Tier 1. Cloudflare postmortem
February 2–3, 2026 — Microsoft Azure: managed identity control plane failures across multiple regions
Between 18:03 UTC on February 2 and approximately 00:30 UTC on February 3, customers saw degraded performance and control plane failures across multiple regions. Resource creation and management for anything with an assigned managed identity failed — Container Apps, AKS, Databricks, PostgreSQL Flexible Servers, Synapse, Copilot Studio and others — and newly created resources of those types could fail to authenticate. Originally communicated under tracking ID _M5B-9RZ.
Flagged pending_primary: the full response timeline for PIR FNJ8-VQZ has not yet been read end to end, so no DLR is computed for this row. Tier 1. Microsoft Post Incident Review, tracking ID FNJ8-VQZ
Archive: 2025 Incidents
November 18, 2025 — Cloudflare: Bot Management feature file
Cloudflare’s published summary attributes the outage to a bug in the generation logic for a Bot Management feature file, which propagated into many Cloudflare services. Duration and diagnostic timestamps are deliberately absent from this row: figures circulating in secondary coverage have not been checked against the postmortem body in a production session, and unverified numbers do not enter this dataset. Flagged pending_primary. Tier 1. Cloudflare postmortem
October 19–20, 2025 — Amazon Web Services, us-east-1: DynamoDB’s DNS automation deleted its own record
The anchor incident of the period, and still the most recent event for which AWS has published a Post-Event Summary. AWS’s own document records three distinct impact windows: DynamoDB API errors from 23:48 PDT on October 19 to 02:40 on October 20; Network Load Balancer connection errors from 05:30 to 14:09 caused by health check failures; and total EC2 launch failures from 02:25 to 10:36, with connectivity problems on newly launched instances persisting to 13:50. The event as a whole ran 23:48 PDT October 19 to 14:20 PDT October 20 — 872 minutes.
The trigger was a latent defect in DynamoDB’s automated DNS management. Amazon determined the cause was DNS resolution failure for the regional DynamoDB endpoint by 00:26 PDT, 38 minutes in, giving this incident a DLR™ of 0.04 — the second-lowest software-caused reading in the log, and a reasonable benchmark for what fast diagnosis looks like at this scale. Tier 1. AWS Post-Event Summary
Download the Dataset
cloud-outage-tracker-august-9-2026.csv — all nine entries, one row per incident, with source_org, source_document, source_url, retrieved_date, is_primary, axis_calculated, and method_note on every row.
Licensed CC BY 4.0.
Cite as: Axis Intelligence Research, Cloud Outage Tracker, 2026.
Every number in the prose above exists as a CSV row at the same value and as-of date. Every DLR™ input is in the file, so the metric can be recomputed independently.
Frequently Asked Questions
How often is this tracker updated?
Weekly, on Sundays, plus an out-of-cycle update within 24 hours of any Tier 1 incident. The Last updated stamp at the top of the page moves only when an entry or figure changes — never as a freshness gesture.
Why is there no AWS entry for 2026?
Because AWS has not published one. Its Post-Event Summaries archive, checked on August 9, 2026, lists the October 19, 2025 DynamoDB disruption as the most recent entry. AWS commits to a PES only for issues meeting a broad-impact threshold, so 2026 regional events that fell below that bar appear on the AWS Health Dashboard’s rolling twelve-month service history without a written summary. This tracker requires a written document, so those events are not logged.
Does a low Diagnostic Lag Ratio mean a provider handled the outage well?
No, and the metric should not be read that way. DLR measures one narrow thing: what share of an outage elapsed before the operator identified the cause. Google’s europe-west4-a failure scores 0.00 and still ran nearly fifteen hours. A low DLR with a long duration points at recovery capability; a high DLR points at observability and investigation.
Why include DENIC alongside the cloud providers?
Because the practical outcome is identical. A registry-level DNSSEC failure makes millions of domains unreachable regardless of who hosts them or which cloud they run on, and it belongs in any honest accounting of infrastructure failure. Inclusion is limited to registry operators of top-level domains, not to individual DNS hosting providers.
Can I use this data?
Yes. The CSV is CC BY 4.0 — reuse it commercially or otherwise with attribution to Axis Intelligence Research. Corrections and additions go to [email protected]; incidents meeting the inclusion criteria will be added and credited.
Methodology and Review Trigger
Entries are compiled by reading operator-published incident documents directly. Search engines are used only to locate those documents, never to supply figures. Where an operator’s own account contains contradictory numbers, both are recorded and the row is flagged.