Cloudflare Logged 13 Incidents in 8 Days This Month. Here's the Actual Fix, Not 'Go Multi-Cloud.'
Cloudflare's status page recorded 13 separate incidents between August 7 and August 14, 2026. R2 object storage failed in the Eastern North America region on the 7th. A Durable Objects and Workflows availability drop hit on the 14th. In between: 503s on Magic Transit, elevated error rates on Workers KV, authentication failures on the MCP Server Portal, and regional 5xx spikes in Kuwait, Bangkok, Jakarta, and Dammam. Workers KV had another elevated-error-rate incident in Western Europe as recently as August 31, and a separate incident hit HTTP 5xx errors in Singapore on August 28. None of these individually matched the scale of the November 2025 global outage. That's exactly why the count matters more than any single line item.
What actually broke, and when
The pattern is worth naming precisely because it's not one root cause repeated. It's R2, then Durable Objects, then Workers KV, then a regional network layer, then an auth service, spread across two and a half weeks and touching different parts of the platform each time. If you run a single service behind Cloudflare, you probably felt one or two of these as "huh, weird 500s for twenty minutes" and moved on. If you run several things across R2, Workers, and KV, like a lot of solo stacks do because Cloudflare made all three genuinely easy to reach for, the odds you dodged all 13 were low.
Why "just diversify" is the wrong advice for one person
Every infrastructure postmortem thread eventually produces someone saying "this is why you need multi-cloud redundancy." That's correct advice for a team with a platform engineer whose job is exactly this. It's close to useless advice for a solo operator, because the engineering cost of real multi-provider redundancy, duplicate storage, duplicate edge compute, health checks, failover logic, testing the failover logic, almost always exceeds the cost of the downtime it's meant to prevent. I've done the math on this for my own setup more than once and it doesn't pencil out below a certain revenue level. Building true redundancy against an outage that costs you a few hours of degraded service a couple times a year is optimizing for the wrong risk.
What's actually worth doing instead
The useful distinction isn't "single cloud vs. multi-cloud," it's separating what's genuinely stateful in your stack from what's cosmetic. Your database and your auth are stateful: an outage there means data loss risk or users locked out, and that's worth real mitigation, even if the mitigation is just "know your database provider's actual SLA and have a tested backup restore process," not a live failover. A CDN cache miss or a KV read hiccup is usually cosmetic: annoying, visible, and recoverable the moment the incident clears, with no lasting damage if you didn't build a hard dependency into a critical path. The 13 incidents in August hit a mix of both categories, and the response should have been different for each. Panicking about a Workers KV blip the same way you'd panic about a database failure is how solo operators burn a weekend rebuilding infrastructure they didn't need to touch.
The systemic point underneath the individual fix
It's also worth saying plainly: a meaningful share of the modern web, DNS, CDN, edge compute, object storage, now sits behind the same small handful of providers. That's a real concentration-risk fact, not a scare story, and it's true independent of what any one person does about their own stack. Knowing that is useful context for reading the next big outage headline. It doesn't obligate you to personally solve the internet's architecture problem.
What I'd actually do
I audited which of my own services touch R2, Durable Objects, or Workers KV on a critical path, meaning something breaks for a user if that specific piece is down, versus a nice-to-have path. Two things moved off a hard KV dependency onto a boring database read with a longer cache TTL, which costs me almost nothing in performance and removes one more thing that can page me over an edge-layer blip. I didn't add a second cloud provider anywhere. For where I am right now, that would be solving a problem I don't have at the cost of one I'd definitely create.
Author
Lukas
@lukcombinator