Cloudflare Outages: Checking Shared Vendor Dependencies

Between August 7 and August 14, 2026, Cloudflare's own status page logged twenty separate incidents. R2 object storage, Workers KV, the MCP Server Portal, Workers AI, Magic Transit, Durable Objects and Workflows. Plus regional network problems touching Querétaro, several Middle East and Southeast Asia points of presence, the Eastern US, London, and Fuzhou/Foshan.

Most were logged as Minor or left unclassified. One wasn't: a major-severity Email Security and Spamhaus disruption on August 12 (Cloudflare status API).

None of this made the headlines Cloudflare's global outage in November 2025 did (Cloudflare's postmortem). That's not because the company got sloppier over nine months. A large product portfolio can generate many scoped incidents. This eight-day count does not by itself establish a normal incident rate or the share of customers affected.

This isn't about the news cycle. It's about what an eight-day cluster like this should change about how you plan.

One incident, examined closely

On August 7, writes to a small set of R2 buckets in the ENAM region started failing at 14:52 UTC. By 22:54 that evening, Cloudflare said it had found the cause and stopped further damage. The status update still read "continuing to work to restore normal availability" at 23:05.

Full restoration wasn't confirmed until 02:35 UTC on August 9 — more than a day after the writes first failed. Some customers reported in Cloudflare's community forum that a slice of their data, tens of gigabytes in at least one case, never came back (Cloudflare community).

That's the current incident. Set it next to an older one, because the older one explains a failure mode that has nothing to do with bad luck.

In March 2025, R2 went down for 67 minutes during what should have been routine maintenance: rotating storage credentials. The engineers running the rotation issued their Wrangler commands without the --env production flag. The new credentials deployed to the default development Worker instead of the production one.

When the old credentials were then deleted — the normal next step in any rotation — production R2 lost the only valid authentication it had. Writes failed 100%. Reads failed at roughly 35%. Image uploads, Stream uploads, and Vectorize inserts all failed completely (Cloudflare's postmortem).

No exploit, no hardware fault, no capacity limit. One missing command-line flag, run by hand, on a change that touched every customer using that storage layer at once.

The lesson, translated for your stack

Cloudflare's own fix wasn't "be more careful." It was structural: replace manual CLI credential rotation with mandatory automated tooling that enforces the environment setting itself, add formal two-person review for credential changes, and add automated health checks that confirm new credentials actually propagated before the old ones get deleted (Cloudflare's postmortem).

That's the pattern worth borrowing, not the incident itself. One manual step took down production for one of the best-resourced infrastructure teams in the world. The same manual step at your own shop carries the same risk, just at your scale instead of theirs.

Your vendor's outage becomes your outage the moment your product depends on their uptime. Your own manual credential rotations, your own hand-run deploy scripts, your own "someone SSHed in and fixed it" habits — that's the same failure mode wearing your logo. Fix the process, not the person who happened to be on call that day.

Bundling multiplies the blast radius

Picture a house running electricity, water, gas, and internet through one provider. That provider has one bad day, and all four go out at once, not just one. A tech stack works the same way: when CDN, DNS, object storage, and compute all sit with one vendor, a shared failure can affect several layers together, although a product-specific incident may affect only one.

Separating providers can reduce some shared failures, but a critical layer such as DNS can still stop the whole service. One provider also does not mean every incident affects every product. Map dependencies and test backup paths that actually avoid the failed components.

Why this is routine now, not exceptional

Cloudflare fronts 24.8% of all websites W3Techs tracks, and 84.4% of sites that use any identifiable reverse proxy at all. Those reported shares describe adoption, rather than establishing which provider a buyer should choose (W3Techs). The figures and incident list describe different measures. Market share alone does not predict incident frequency or severity.

What an SME infra review should check

1. Map every layer. DNS, CDN, object storage, compute — count how many trace back to one vendor. Write the number down; most owners have never counted it.
2. Check how credentials actually get rotated. A manual CLI command run by one person from memory is the exact pattern that caused the March 2025 outage. If your process looks like that, mandated tooling and a second reviewer close the gap cheaply.
3. Confirm a degraded-mode plan exists on paper — a cached fallback, a read-only mode, an alternate DNS path — for the hour the status page turns red. Not a plan to prevent the outage. A plan for what your business does while it's happening.

A single point of failure rarely announces itself before the day it matters. Knowing an incident is underway before a customer tells you is half the battle either way.

The actual signal

Twenty incidents in eight days didn't trend anywhere, and that's the detail worth sitting with. A global, single-day outage earns a postmortem, a news cycle, and a week of renewed attention to redundancy. A steady drip of Minor-severity incidents earns none of that — it gets ignored, right up until the week your account sits in the blast radius.

Plan from the dependencies your service uses, incident scope, and tested recovery paths. A short cluster of status entries alone does not measure your future risk.