Cloudflare’s status page logged 13 separate incidents between August 7 and August 14, 2026, touching R2 object storage, Durable Objects, Workers KV, Workers AI, and network performance across four continents. None of the individual incidents matched the scale of the company’s November 18, 2025 global outage, but the sheer frequency has reopened a question DevOps teams keep asking: what happens when one company sits in front of roughly a fifth of the web’s traffic and something breaks, over and over, in the same week?
The cluster of incidents started with an R2 storage failure in Cloudflare’s Eastern North America (ENAM) region on August 7 and stretched through a Durable Objects and Workflows availability drop on August 14. In between, customers hit 503 errors on Magic Transit, elevated errors on Workers KV, authentication failures on the MCP Server Portal, and regional 5xx spikes in Kuwait, Bangkok, Jakarta, and Dammam. Each incident on its own reads as routine. Stacked together across eight days, they paint a picture of a network under sustained strain even as the company reports record revenue growth.
What Happened: Cloudflare’s August 2026 Incident Streak
Cloudflare’s own status history, published at cloudflarestatus.com/history, shows the run began on August 7 with a write-availability problem affecting a small number of R2 buckets in ENAM between 14:52 and 17:02 UTC. Recovery dragged into August 8, when a second, unrelated issue hit network performance in Istanbul after Cloudflare reported a loss of dark fiber connectivity in the region. Three days of relative quiet followed before the pace picked back up on August 11, with connectivity errors in London and a batch of scheduled storage maintenance.
From August 12 onward, the incidents came almost daily. August 12 brought a major-severity email security disruption tied to a Spamhaus listing that affected outbound delivery. August 13 produced four separate incidents in a single day: increased 503 errors when customers made changes to Magic Transit through the dashboard and API, elevated errors on Workers KV requests, intermittent authentication failures on the MCP Server Portal, and errors on Workers AI for specific models. August 14 closed the window with four more: a Durable Objects and Workflows availability drop, network congestion in the Eastern US, HTTP 5xx errors across four Middle Eastern and Southeast Asian markets, and a network performance issue in Querétaro, Mexico.
The R2 Storage Outage: ENAM Buckets Go Dark
The R2 incident on August 7 is the one drawing the most developer attention, because object storage failures carry higher stakes than a dashboard glitch. Cloudflare’s status updates described the impact as writes failing for “a small number of buckets” in the ENAM region, with the company saying it had identified the cause by 22:54 UTC that day and was working to restore full access. Recovery for most buckets came within roughly a day, but a subset of objects uploaded through multipart uploads during the initial window took longer to reappear.
In Cloudflare’s own community forum, at least one customer reported that data in an R2 bucket named “comfy-storage” had not come back after the incident, citing roughly 67GB left unrestored days later. Cloudflare has not published a formal postmortem confirming permanent data loss for that case as of August 15, and the company’s public status updates describe the incident as resolved. The gap between a status page marked “resolved” and individual customers still missing files is a recurring friction point for any provider running infrastructure at Cloudflare’s scale, and it’s a big reason engineering teams treat R2, S3, and similar object stores as needing their own backup strategy rather than trusting a single region’s durability guarantee.
Durable Objects and Workflows: The August 14 Availability Drop
The final incident in the window, a “Durable Objects and Cloudflare Workflows availability drop,” resolved the same day it started, August 14, with Cloudflare marking it minor severity. Durable Objects underpin a growing share of stateful applications built on Cloudflare Workers, from chat backends to coordination logic for multiplayer apps, and Workflows is the company’s newer durable-execution product for long-running, retryable tasks. An availability drop in either service doesn’t just slow page loads; it can stall in-flight business logic that developers assumed would complete reliably in the background.
Cloudflare classified the incident as minor and resolved it within hours, a contrast to the multi-day R2 recovery earlier in the window. That gap matters for anyone trying to gauge risk: not every line on a status page carries the same weight, and lumping a 90-minute Workers AI hiccup in with a multi-day storage recovery flattens a distinction operations teams need when deciding where to add redundancy first.
A Timeline of the August 2026 Incidents
Here’s the full run of incidents Cloudflare logged on its public status page between August 7 and August 14, 2026, excluding routine scheduled maintenance windows in individual data centers.
| Date (2026) | Incident | Service Affected | Severity |
|---|---|---|---|
| Aug 7 | R2 write availability drop, ENAM buckets | R2 Object Storage | Minor |
| Aug 8 | Network performance issue, dark fiber loss | Network (Istanbul) | Minor |
| Aug 11 | Connectivity errors, London | Network (UK) | Minor |
| Aug 11 | Analytics delays | Cloudflare Analytics | Minor |
| Aug 12 | Email delivery impacted by Spamhaus listing | Email Security | Major |
| Aug 13 | 503 errors on dashboard/API changes | Magic Transit | Minor |
| Aug 13 | Increased request errors | Workers KV | Minor |
| Aug 13 | Intermittent authentication failures | MCP Server Portal | Minor |
| Aug 13 | Errors with specific models | Workers AI | Minor |
| Aug 14 | Availability drop | Durable Objects / Workflows | Minor |
| Aug 14 | Network congestion, Eastern US | Network (US) | Minor |
| Aug 14 | HTTP 5xx errors, Kuwait/Bangkok/Jakarta/Dammam | Network (multi-region) | Minor |
| Aug 14 | Network performance issue, Querétaro | Network (Mexico) | Minor |
Thirteen incidents in eight days works out to more than one and a half per day on average, though the real pattern is bursty: three quiet days in the middle of the window, then four incidents apiece on August 13 and 14. Twelve of the 13 carried a minor-severity label; only the Spamhaus-related email disruption on August 12 was rated major.
Why Cloudflare Outages Hit So Hard: The Concentration Risk
Cloudflare’s scale is exactly why a run of minor incidents makes news. According to W3Techs, Cloudflare acted as the reverse proxy for 24.2% of all websites as of late July 2026, an 84.1% share among sites where a reverse proxy provider could be identified at all. The company itself has said it handles more than a fifth of global internet request traffic. That footprint means a regional network hiccup in Querétaro or a Workers KV error spike doesn’t stay contained to Cloudflare’s own dashboards. It shows up as a slow checkout page, a failed login, or a broken API call for thousands of businesses that never chose to depend on any single vendor that directly, they just used a CDN.
This is the structural bind of edge computing at Cloudflare’s scale. Centralizing DNS, CDN, WAF, and now serverless compute (Workers, Durable Objects, Workflows) and object storage (R2) behind one provider cuts operational overhead for customers who’d otherwise stitch together five vendors. It also means the blast radius of any single incident spans DNS resolution, page delivery, authentication, and application logic at once, rather than failing in one isolated layer. When Cloudflare’s status page shows four incidents on the same day, as it did on both August 13 and August 14, that’s four different subsystems degrading independently, not one root cause cascading.
Historical Context: From the March 2025 Credential Error to Today
Cloudflare’s August 2026 run isn’t the company’s first brush with an R2-specific failure. On March 21, 2025, an R2 outage traced back to a credential rotation error: an engineer omitted the --env production flag when deploying new storage credentials, so the new credentials landed in a development Worker instead of production. When the old credentials were deleted as part of the routine rotation, production R2 was left without valid authentication. Cloudflare’s own postmortem, published at blog.cloudflare.com, put the incident at 1 hour and 7 minutes, from 21:38 to 22:45 UTC, with 100% of write operations and roughly 35% of read operations failing during that window. Coverage of the incident, including a writeup at BleepingComputer, noted Cloudflare’s fix: requiring at least two engineers to sign off on high-impact credential changes going forward.
That March 2025 incident and the August 2026 ENAM write failure aren’t the same root cause, but they share a pattern: R2’s write path has now shown up in two separate public incidents in under a year and a half, each affecting a subset of customers hard enough to generate community forum threads and press coverage, even though neither reached the scale of Cloudflare’s true worst-case scenario.
The November 2025 Outage: How a Database Change Took Down Half the Internet
That worst case happened on November 18, 2025. According to Cloudflare’s own postmortem at blog.cloudflare.com, a routine database permissions change at 11:05 UTC caused a ClickHouse query that generated Cloudflare’s Bot Management feature file to return duplicate column metadata. The feature-generation logic didn’t filter results by database, so the file it produced doubled in size, well past a 200-feature hard limit built into the core proxy service. The oversized file triggered a panic in the proxy: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value.” Core traffic saw HTTP 5xx errors from 11:20 UTC, with the bulk of services restored by roughly 14:30 UTC and full resolution by 17:06 UTC, a window of just under six hours from first impact to close.
The affected list read like Cloudflare’s entire product catalog: core CDN and security services, Turnstile (which failed to load entirely), Workers KV, the Cloudflare dashboard itself (locking some customers out mid-incident), Cloudflare Access, and Email Security’s IP reputation lookups. Against that backdrop, the August 2026 run of 13 minor and one major incident looks tame. But it’s also a reminder that the underlying conditions, a network dense enough that a single bad deploy or a permissions change can ripple across a dozen products at once, haven’t gone away just because the November postmortem’s fixes shipped.
Cloudflare vs. AWS vs. Azure vs. Google Cloud: Reliability Compared
Cloudflare doesn’t operate in a vacuum, and 2025-2026 hasn’t been a clean run for any major infrastructure provider. AWS’s us-east-1 region hit a 28-hour outage that shattered.io’s own reporting covered as the third major us-east-1 failure in recent memory, and outage-tracking analysis from Hokstad Consulting put AWS’s 2023-2025 average uptime at 99.95% with average recovery times of roughly 2.8 hours, against Azure’s slightly higher 99.97% average uptime but longer average recovery of about 4.2 hours. Google Cloud, meanwhile, has generally logged fewer major outages than AWS over the same period, even as it posted the fastest revenue growth of the big three hyperscalers, a trend shattered.io covered when Google Cloud’s growth rate outpaced both AWS and Azure.
| Provider | Reported Avg. Uptime (2023-2025) | Avg. Recovery Time | Notable 2025-2026 Incident |
|---|---|---|---|
| AWS | ~99.95% | ~2.8 hours | 28-hour us-east-1 outage |
| Azure | ~99.97% | ~4.2 hours | October 2025 Front Door failure (global) |
| Google Cloud | Fewer major outages than AWS | ~3 hours (June 2025 incident) | Service Control overload took down Discord, Spotify |
| Cloudflare | Not separately published in this dataset | 1h7m (Mar 2025 R2) to ~6h (Nov 2025 global) | 13 incidents, Aug 7-14, 2026 |
The comparison is imperfect. Cloudflare doesn’t publish an aggregate uptime percentage the way SLA-driven hyperscalers do, and its status page counts far more granular, service-level incidents than AWS or Azure typically disclose publicly, which inflates Cloudflare’s visible incident count relative to competitors who may have similar rates of small failures but less transparent reporting. Still, the pattern across all four providers points to the same conclusion: single-region and single-vendor dependency remains the biggest reliability risk in cloud architecture, regardless of which logo is on the outage.
Market Impact: Record Revenue Growth Alongside the Outages
The incident streak lands at an odd moment for Cloudflare’s business. The company’s second-quarter 2026 results showed revenue of $696.1 million, up 36% year over year, with non-GAAP earnings per share up 38.1%. Cloudflare added more than 80,000 paying customers in the quarter, pushing year-over-year paying-customer growth to 74%, and closed the period with 4,698 customers generating more than $100,000 in annualized revenue, up 27% year over year. Large customers, those $100,000-plus accounts, made up 73% of quarterly revenue, and the company added nearly 2 million developers to its platform in the quarter, bringing its developer total past 7.4 million. Cloudflare’s full-year guidance points to $2.864 billion to $2.870 billion in revenue, roughly 32% growth.
None of those figures came from the August incident window itself, they’re Q2 results reported before the incidents in this article occurred, but they establish the backdrop: Cloudflare is growing paying customers and developer adoption faster than most of its peers even as its status page logs a steady drip of service disruptions. Whether that drip becomes a drag on renewal rates or competitive win-loss numbers likely won’t show up until the company’s next earnings call, when analysts get their first chance to ask directly about the August incident count.
The Multi-CDN Question: Are Companies Rethinking Dependency?
Every time Cloudflare has a bad week, the same conversation resurfaces in engineering Slack channels and on Hacker News: should critical infrastructure sit behind more than one CDN and DNS provider? The honest answer is that multi-CDN failover is expensive and operationally complex enough that most companies, even ones that can afford it, don’t fully implement it until after a painful outage forces the question. Running true DNS and CDN redundancy means duplicating WAF rules, cache behavior, and TLS configuration across providers, then building automated failover logic that’s tested regularly rather than left to rot until the day it’s needed.
For services built specifically on Cloudflare’s edge compute stack, Workers, Durable Objects, R2, the multi-provider question gets harder still, because there’s no drop-in equivalent at another vendor that replicates Cloudflare’s specific programming model. A company that built its backend logic around Durable Objects’ actor model can’t just point DNS at a competitor during an incident; it would need a parallel implementation on a different platform, maintained and tested continuously. That’s a much bigger lift than classic CDN failover, and it’s part of why so many teams accept the risk of concentration in exchange for the developer velocity Cloudflare’s platform provides.
What Cloudflare Says It’s Doing to Fix It
Cloudflare’s public postmortems from its two most significant recent incidents both describe concrete process changes rather than only technical patches. After the March 2025 R2 credential incident, the company said it would require two-person validation for high-impact credential changes and mandate automated deployment processes rather than manual command-line steps that leave room for a missed flag. After the November 2025 global outage, the company’s postmortem pointed to hardening the feature-file generation pipeline against malformed or duplicated database output, and reviewing hard-coded limits like the 200-feature cap that turned a data quality bug into a full proxy crash.
What’s less clear is whether the August 2026 run of 13 incidents reflects a gap in those fixes or simply the normal background rate of running infrastructure at Cloudflare’s scale, where thousands of deploys, config changes, and regional network events happen every week and a certain number will always go wrong. Cloudflare has not published a synthesis postmortem covering the full August 7-14 window as of this writing; each incident got its own brief status update rather than a unified root-cause analysis.
Predictions: Where Cloudflare’s Reliability Story Goes Next
- Expect Cloudflare to publish at least one detailed postmortem covering the R2 ENAM incident specifically, given the community reports of unrestored data, rather than leaving it as a status-page footnote.
- Watch for Cloudflare’s Q3 2026 earnings call, expected around early November, to include a direct analyst question about the August incident count and any customer churn tied to it.
- Multi-CDN and multi-DNS tooling vendors are likely to see a bump in inbound interest through Q4 2026, following the same pattern seen after the November 2025 outage.
- Cloudflare’s R2 product will probably get additional durability guarantees or clearer SLA language in the coming months, given this is the second R2-specific incident to draw public attention in under 18 months.
- Competitors, particularly Fastly and Akamai, are likely to reference Cloudflare’s August incident count in competitive sales conversations, even though their own status pages report on a less granular basis and aren’t directly comparable.
Frequently Asked Questions
How many Cloudflare outages happened in August 2026?
Cloudflare’s public status page logged 13 separate incidents between August 7 and August 14, 2026, spanning R2 storage, Durable Objects, Workers KV, Workers AI, email security, and regional network performance. Twelve were rated minor severity; one, an email delivery disruption tied to a Spamhaus listing on August 12, was rated major.
Was any customer data permanently lost in the R2 outage?
Cloudflare’s official status updates describe the R2 ENAM incident as resolved, but at least one customer reported in the company’s community forum that around 67GB of data in an R2 bucket had not been restored days after the incident. Cloudflare had not published a formal postmortem confirming or denying permanent data loss for that case as of August 15, 2026.
How does this compare to Cloudflare’s November 2025 outage?
The November 18, 2025 outage was far larger in scope, taking down core CDN, Turnstile, Workers KV, the Cloudflare dashboard, and Access simultaneously for close to six hours, caused by a database permissions change that corrupted a Bot Management feature file. The August 2026 incidents were smaller and more distributed across the week, none matching the November event’s blast radius.
What percentage of the internet runs through Cloudflare?
According to W3Techs, Cloudflare served as the reverse proxy for 24.2% of all websites as of late July 2026, an 84.1% share among sites where a reverse proxy provider could be identified. Cloudflare has said it handles more than a fifth of global internet request traffic.
Did the outages affect Cloudflare’s stock or financial results?
Cloudflare’s Q2 2026 earnings, reported before this incident window, showed revenue of $696.1 million, up 36% year over year, and 74% year-over-year paying-customer growth. Those results predate the August incidents, so any financial impact from this specific run of outages won’t be visible until the company’s next earnings report.
Should companies use a multi-CDN strategy to avoid Cloudflare outages?
It depends on what’s built on Cloudflare. Classic CDN and DNS failover to a second provider is achievable, though operationally costly. Applications built directly on Cloudflare-specific products like Durable Objects or Workflows are harder to make portable, since there’s no drop-in equivalent at competing providers, which is part of why full multi-provider redundancy remains rare even among large Cloudflare customers.
What caused the March 2025 Cloudflare R2 outage?
A credential rotation error. An engineer omitted the --env production flag while deploying new R2 storage credentials, so the new credentials went to a development Worker instead of production. When the old credentials were deleted as part of the rotation, production R2 lost valid authentication, causing 100% write failures and roughly 35% read failures for 1 hour and 7 minutes.
Are AWS and Azure more reliable than Cloudflare?
The comparison isn’t apples-to-apples. AWS has reported average uptime near 99.95% with roughly 2.8-hour average recovery times over 2023-2025, and Azure roughly 99.97% uptime with about 4.2-hour average recovery, according to outage-tracking analysis. Cloudflare doesn’t publish an equivalent aggregate uptime figure and discloses more granular, service-level incidents publicly, which makes its status page look busier even though the underlying failure rate may not be meaningfully different from its hyperscaler peers.
Related Coverage
- AWS Outage Hits 28 Hours, Third us-east-1 Failure [2026]
- Google Cloud Hits 63% Growth, Outpaces AWS, Azure [2026]
- Cloudflare Workers Setup: 12 Steps, 30 Min [2026]
- Xbox Down 15 Hours: Second Outage in a Week [2026]
- PSN Outage Delays $1M Esports Final, Sony’s 7th [2026]
For more coverage of cloud infrastructure reliability and outages, visit shattered.io’s cloud computing section.
