Cloudflare's Rough August: 13 Incidents in 8 Days

Between August 7 and August 14, 2026, Cloudflare’s own status page logged 13 separate incidents. Not one bad day, thirteen entries across a week, touching R2 object storage, Durable Objects, Workers KV, Workers AI, email security, and network performance across four continents. Twelve were classified minor. One, an email delivery disruption tied to a Spamhaus blocklist listing on August 12, was rated major. By August 15, Cloudflare hadn’t published a formal postmortem, and at least one customer reported in the company’s community forum that roughly 67GB of data in an R2 bucket still hadn’t come back.

None of that means Cloudflare is suddenly unreliable in some fundamental way. It means something more specific and more useful: a week like this is a live demonstration of what “one provider, many products” actually risks, and it’s worth thirty minutes of architecture review even if your R2 bucket was never touched.

The week, briefly

Thirteen incidents in eight days is a lot even accounting for how status pages count things, since a single underlying issue can generate multiple status entries as it cascades or gets updated. What stands out isn’t any single incident’s severity, most were minor, it’s the spread across products that look independent from the outside. R2 is object storage. Durable Objects is a stateful compute primitive. Workers KV is a key-value store. Email security is, obviously, email. A customer choosing Cloudflare for one of these products generally isn’t thinking about the others, which is exactly why a week where several of them wobble at once is informative: it’s a hint that the failure domains aren’t as separate underneath as the product names suggest.

The unresolved R2 data question is the part worth actually watching. A specific customer report of unreturned data, days after the incident, with no public postmortem yet, is a different category of problem than “the dashboard was slow for twenty minutes.” It’s also, as of this writing, unconfirmed as a wider pattern rather than an isolated case, which is exactly the kind of ambiguity that makes it worth checking your own Cloudflare-dependent backups rather than assuming someone else’s experience doesn’t apply to you.

It’s not just Cloudflare, and that’s the actual point

The same window saw a fourth notable AWS-linked reliability incident since May 2026: a data center thermal event in Northern Virginia in May, a network disruption in June that also rippled into Cloudflare, and back-to-back US-WEST-2 connectivity issues in July and again in early August. Two major infrastructure providers, both usually treated as close to a safe default, both had a rougher few months than their historical reputation would predict.

That’s the pattern to internalize, more than any single incident. We covered the mechanics of a single Cloudflare postmortem in February, the kind of deep architectural read that’s genuinely useful once a company publishes one. August is a different lesson: sometimes what matters isn’t the root cause of one outage, it’s the frequency and spread of smaller ones, because that’s the signal that a provider’s overall reliability posture has shifted, even before any individual incident is bad enough to make headlines on its own.

What to actually check this week

Map your failure domains honestly. If your primary storage, your DNS, and your edge compute all sit with the same provider, write down what happens to each one independently if that provider has a bad week like this one. If the honest answer is “everything degrades together,” that’s the gap to close, not necessarily by leaving the provider, but by making sure your DR plan doesn’t quietly assume independence that doesn’t exist.

Test your actual restore path, not just your backup job. A backup that runs successfully every night tells you writes are happening. It tells you nothing about whether a restore works when the provider hosting both your primary data and your backup copy is the one having the incident. If your R2 bucket is your only copy of something that matters, that’s worth revisiting regardless of what caused this particular week.

Separate your status page dependency from your provider dependency. A lot of teams only find out about a degraded dependency when their own users start complaining, because they’re watching their own metrics dashboard, which is itself sometimes hosted on the same infrastructure that’s degrading. A status-page monitor that’s genuinely independent of your primary provider is cheap insurance.

Don’t overreact into a multi-cloud project you don’t need. Full multi-cloud redundancy for every workload is expensive and often adds more operational risk than it removes, especially for a small or mid-size engineering team. The proportionate response to a week like this one is targeted: identify the two or three things that would actually hurt if this provider had a genuinely bad day, and make sure those specific things have an independent path, not a wholesale platform migration.

Reliability incidents cluster more than most uptime dashboards suggest, and the response that actually helps isn’t panic or provider-switching, it’s an honest look at which of your systems assume independence that a week like this one just showed doesn’t hold. If that kind of resilience review isn’t already part of your quarterly planning, our infrastructure and architecture work is built around exactly that kind of assumption-testing before it costs you an incident of your own.