Cloudflare Logged 13 Outages in Eight Days This Month: What a Single Point of Failure Really Costs a Small Business Website

Cloudflare's own status page logged 13 separate incidents in eight days this month, between August 7 and August 14, 2026. They touched R2 object storage, Durable Objects, Workers KV, Workers AI, email security, and network performance on four continents. Individually, almost every one of them was small. Stacked together in a single week, they reopened a question infrastructure teams keep circling back to: what happens when one company sits in front of roughly a quarter of the web's traffic and something breaks, repeatedly, in the same stretch of days.

For a reader running a shop, a clinic, a small agency, or a food business online, the company names in this story, Cloudflare, R2, Durable Objects, can sound like someone else's problem. They are not. A large share of the internet's DNS, CDN, and object storage runs through a small number of providers, and a small business website usually depends on at least one of them without anyone on staff ever having chosen it directly, because it came bundled with a hosting plan, a page builder, or a developer's default stack. When that provider has a rough week, a checkout page slows down, a product photo fails to load, or a contact form stops submitting, and the business owner has no idea why.

This article separates what Cloudflare's status page actually recorded from what the run means for a small business that has never read a status page in its life.

🧭 What Cloudflare's Status Page Actually Recorded

Cloudflare publishes a public incident history at cloudflarestatus.com/history, and it is the primary record for this story. Between August 7 and August 14, 2026, the page logged 13 incidents outside routine scheduled maintenance in individual data centers, according to a timeline compiled by technology outlet Shattered.io from that same public history.

The run started on August 7 with a write-availability problem affecting a small number of R2 storage buckets in Cloudflare's Eastern North America (ENAM) region, between 14:52 and 17:02 UTC. Recovery stretched into August 8, when a second and unrelated issue hit network performance in Istanbul after Cloudflare reported losing dark fiber connectivity in the region. Three quieter days followed. Then, from August 11 onward, the pace picked back up: connectivity errors in London, a batch of scheduled storage maintenance, and on August 12 a major-severity email security disruption tied to a Spamhaus listing that affected outbound mail delivery for some customers.

August 13 and 14 were the busiest days in the window, with four separate incidents apiece. On August 13: increased 503 errors when customers made changes to Magic Transit through the dashboard or API, elevated errors on Workers KV requests, intermittent authentication failures on the MCP Server Portal, and errors on Workers AI for specific models. On August 14: a Durable Objects and Cloudflare Workflows availability drop centered on Miami-based colocations, network congestion in the Eastern United States, HTTP 5xx errors across Kuwait, Bangkok, Jakarta, and Dammam, and a network performance issue in Queretaro, Mexico.

Cloudflare's own status page confirms the shortest of these. The Durable Objects and Workflows incident opened at 3:27 PM EDT on August 14, when the team said it was mitigating an availability drop, and closed 38 minutes later.

That single incident is a useful anchor for the whole story: fast to identify, fast to fix, and rated minor. Most of the 13 incidents followed that same shape. The R2 storage failure on August 7 did not.

🗄️ Why the R2 Storage Failure Drew the Most Attention

Object storage failures carry higher stakes than a dashboard glitch, because they touch the actual files a website or application depends on to run: product images, backups, uploaded documents, generated assets. Cloudflare's status updates described the August 7 impact as writes failing for a small number of buckets in the ENAM region. The company said 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 according to Shattered.io's reporting, a subset of objects uploaded through multipart uploads during the initial window took longer to reappear.

At least one customer reported in Cloudflare's own community forum that data in an R2 bucket had not come back after the incident, citing roughly 67GB left unrestored days later, per Shattered.io. Cloudflare has not published a formal postmortem confirming permanent data loss for that specific case, and the company's public status updates describe the incident as resolved. That gap between a status page marked resolved and an individual customer still missing files is not unique to Cloudflare. It is a structural feature of running infrastructure at this scale, and it is the main reason engineering teams treat object storage the same way they treat any single vendor: worth its own independent backup, not just a status page's word that everything came back.

⚙️ Durable Objects and the Cost of Bundling Everything Together

The last incident in the window, the Durable Objects and Workflows availability drop, resolved the same day it started and was the fastest of the thirteen. 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 Cloudflare's newer product for long-running, retryable background tasks. An availability drop in either service does not just slow a page load. It can stall business logic a developer assumed would finish reliably in the background, things like a payment confirmation step or an order status update.

Cloudflare rated the incident minor and closed it within 38 minutes, a sharp contrast to the multi-day R2 recovery a week earlier. That gap matters for anyone trying to gauge real risk from a status page: not every logged incident carries the same weight, and treating a 38-minute service hiccup the same as a multi-day storage recovery flattens a distinction that actually matters when deciding where to invest in redundancy first.

🌐 The Concentration Risk Behind the Headline

Cloudflare's scale is exactly why a run of mostly minor incidents becomes a story at all. According to W3Techs, which tracks reverse proxy usage across the web, Cloudflare served as the reverse proxy for roughly a quarter of all websites it measured as of August 2026, and more than four in five sites where a reverse proxy provider could be identified at all. Cloudflare has separately said its network handles more than a fifth of measured global internet traffic.

That footprint means a regional network hiccup in Queretaro or an elevated error rate on Workers KV does not stay contained to Cloudflare's own dashboard. 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, or their hosting provider did.

This is the structural trade-off of edge computing at Cloudflare's scale. Centralizing DNS, CDN, web application firewall, and now serverless compute and object storage behind one provider cuts operational overhead for a business that would otherwise have to stitch together five separate vendors. It also means the blast radius of any single incident can span DNS resolution, page delivery, authentication, and application logic all at once, rather than failing in one isolated layer. When Cloudflare's status page logged four separate incidents on both August 13 and August 14, that was four different subsystems degrading independently on each day, not one root cause cascading through the network.

📊 How This Run Compares to Cloudflare's Worst Day

Cloudflare's August 2026 run is not its first brush with an R2-specific failure, and it is far from the company's worst outage on record. On March 21, 2025, an earlier R2 outage traced back to a credential rotation error during a routine deployment: new storage credentials landed in a development environment instead of production, and when the old production credentials were deleted as part of the rotation, R2 was left without valid authentication. Cloudflare's own postmortem put that incident at one hour and seven minutes, with all write operations and roughly a third of read operations failing during the window. Cloudflare's fix at the time was to require sign-off from at least two engineers before any high-impact credential change.

The far larger event was Cloudflare's global outage on November 18, 2025. According to Cloudflare's own published postmortem, a routine database permissions change triggered a query that generated Cloudflare's bot-management feature file with duplicate data, doubling the file's size past a hard limit built into the company's core proxy software. The oversized file crashed the proxy service outright. Core traffic began returning errors at 11:20 UTC, with most services restored by around 14:30 UTC and full resolution by 17:06 UTC, just under six hours from first impact to close. The affected list that day included Cloudflare's dashboard, its Turnstile verification widget, Workers KV, and Access, locking some customers out of their own accounts mid-incident.

Set against that history, 13 mostly minor incidents in eight days looks tame, and Cloudflare's own severity labels back that reading up: twelve of the thirteen were rated minor, and only the August 12 email disruption was rated major. But the run is still a reminder that the underlying condition that made the November 2025 outage possible, a network dense enough that one bad change can ripple across a dozen products simultaneously, has not gone away simply because that postmortem's fixes shipped.

💰 A Company Growing Fast Even as the Incidents Piled Up

The incident streak landed at an unusual moment for Cloudflare's business. The company's second-quarter 2026 results, announced August 6, 2026, showed revenue of 696.1 million US dollars, up 36 percent year over year, with non-GAAP diluted earnings per share rising to 0.29 US dollars from 0.21 US dollars a year earlier. Cloudflare reported adding a record 986 large customers, those spending more than 100,000 US dollars annually, over the preceding twelve months. None of that growth explains or excuses eight days of incidents a month later, but it does show the incidents were not a sign of a company in decline. They were a sign of a company operating an increasingly large and complex network under continuous load, the same load its customers are paying more for every quarter.

🌏 Why This Matters Even If Your Business Never Heard of Cloudflare

Indonesian small businesses rarely pick a CDN or object storage provider by name. A shop owner buys a hosting package, hands a developer the keys to a WordPress site, or launches through a page builder, and the provider sitting in front of that stack gets chosen once, quietly, and then forgotten. That is not a criticism of how small businesses operate. Nobody running a bakery or a clinic should need to become a network engineer to keep a website online. But it does mean an incident on a provider's status page rarely reaches the business owner directly. It reaches them as a customer message asking why the online order form is not working, or a missed booking because a page took eleven seconds to load during a regional network hiccup.

The four-continent spread in this particular run is a useful detail for exactly that reason. The August 14 incidents alone touched Kuwait, Bangkok, Jakarta, and Dammam directly, alongside the Eastern United States and Queretaro, Mexico. A business in Jakarta relying on a hosting stack that routes through the affected edge location did not need to be a Cloudflare customer by name to feel a slowdown that day. Regional network issues on a shared edge network can surface as a slower page for visitors in one city while the same site loads normally for visitors somewhere else, which is part of why a single bad review about a site being slow does not always mean the whole site is broken.

🧮 Cloudflare Against the Rest of the Field

Cloudflare is not the only large infrastructure provider to have had a rough stretch recently, and it is worth placing this run in that wider context rather than treating Cloudflare as uniquely fragile. Industry outage tracking cited by Shattered.io put Amazon Web Services' average reported uptime for 2023 to 2025 at roughly 99.95 percent with an average recovery time near 2.8 hours, and Microsoft Azure at a slightly higher average uptime near 99.97 percent but a longer average recovery time near 4.2 hours. AWS's own us-east-1 region experienced a 28-hour outage that made headlines earlier in this same period. Google Cloud has generally logged fewer major publicized outages than AWS across recent years even as it posted the fastest revenue growth among the three largest hyperscalers.

Cloudflare does not publish an aggregate uptime percentage the way SLA-driven cloud providers often do, and its public status page logs far more granular, service-level incidents than competitors typically disclose, which can make Cloudflare's visible incident count look higher than rivals with a similarly bumpy quarter but a quieter status page. The comparison across all four providers still points to the same underlying lesson: single-region and single-vendor dependency is the common thread behind nearly every major outage story of the past two years, regardless of which company's logo sits on the postmortem.

🔍 Reading a Status Page Without Overreacting

A status page is not written for a small business owner, and that gap causes most of the confusion during an outage. Cloudflare labels incidents minor, major, or critical, and the label reflects the scope Cloudflare itself measured, not how badly a specific customer's site was affected. A minor label on a Workers KV error, for instance, can still mean a total outage for one small application that leans heavily on that exact feature, even while the vast majority of Cloudflare customers never notice anything. The reverse also happens: a major label on an email security disruption, as with the Spamhaus listing on August 12, can affect almost nobody running a plain website while it seriously disrupts a business that depends on transactional email.

The practical habit worth building is checking the status page for the specific service your site depends on, not the overall page. If a developer says a site's images, DNS, or backend runs on Cloudflare, that is a starting point for a conversation, not the end of one. Ask which specific products are in use: R2 for storage, Workers for backend logic, or simply the CDN and DNS layer most sites use by default. A site that only uses CDN and DNS is far less exposed to a Durable Objects or Workers AI incident than one built as a full serverless application on the same platform.

🇮🇩 What This Looks Like for a Business Based in Indonesia

Indonesian small businesses sit inside this picture in a specific way. Many local hosting providers, page builders, and even some bank and payment gateway integrations route part of their traffic through Cloudflare or a similar global edge network, often without advertising it on a pricing page. A business owner in Surabaya or Medan checking whether their site is affected during an incident window should look first at whether their site loads slowly for visitors in a specific city while loading normally elsewhere, since that pattern points toward a regional edge issue rather than a problem with the site's own code.

Local developers and agencies that build on WordPress, WooCommerce, or a headless storefront frequently add Cloudflare as a free layer for basic DDoS protection and caching, which is a reasonable default for most small sites. The risk is not in using Cloudflare. The risk is in never asking what else runs through the same account: DNS only, or DNS plus image optimization plus a web application firewall plus, increasingly, object storage for product photos and video content. Each additional service adds convenience and also adds one more thing that can be part of the next incident window, whichever provider is behind it.

🏪 What This Actually Means for a Small Business Website

Most small business owners will never read a status page, and they should not need to in order to run a website. What they need is a short, practical response to a week like this one, and four checks cover most of it.

1. Know which services actually sit behind your website. A website builder, a hosting plan, or a developer's stack may route DNS, CDN, image delivery, and even backend logic through the same provider without ever naming it on an invoice. Ask directly: which company handles our DNS, our CDN, and our file storage, and is it the same one for all three.
2. Separate "the whole internet is down" from "our specific setup broke." During any outage, check a public status page and a site like Downdetector before assuming the fault is unique to your business. If a provider's status page shows a resolved incident but your site is still broken, that gap is worth reporting to your developer rather than waiting it out.
3. Keep an independent backup of anything stored with a single provider. Product images, customer data exports, and site backups deserve a copy that does not live only inside the same object storage service the rest of the site depends on. The R2 customer who reported 67GB still missing days after Cloudflare marked the incident resolved is the exact scenario an independent backup protects against.
4. Ask what happens during a provider incident, not just after one. A website that goes fully blank during a CDN hiccup is a different risk than one that degrades gracefully, showing a cached version of the homepage while checkout is briefly unavailable. That difference is usually a configuration choice, not an accident, and it is worth asking a developer about before the next incident, not during it.

None of this requires abandoning a major provider or building a five-vendor stack overnight. Cloudflare's scale is also what makes it fast, affordable, and secure for millions of small sites that could never build equivalent infrastructure themselves. The practical goal is smaller: know your dependencies, keep one backup outside them, and treat a provider's status page as a first stop during any outage, not a mystery to solve from scratch every time.

A useful five-minute drill makes this practical. Open your domain registrar account and record where the DNS nameservers point. Ask the person responsible for your site where its daily or weekly backup is stored and whether you can download it without needing the same provider to be online. Test the contact form from a phone using mobile data, then note who receives the message and where the submission is stored. Finally, write down one person to call if the site is unavailable and one alternate channel, such as WhatsApp Business, where customers can still place an order. These are mundane details until the day a customer cannot reach a business. On that day, they are the difference between an incident that costs a few minutes of attention and one that costs a full day's sales.

Sources: Cloudflare Status History (cloudflarestatus.com/history); Cloudflare Status Dashboard, Durable Objects and Cloudflare Workflows availability drop incident, August 14, 2026; Shattered.io, "Cloudflare Logs 13 Outages in 8 Days as R2 Falters," updated August 16, 2026; W3Techs, Cloudflare usage statistics, August 2026; Cloudflare, Second Quarter 2026 Financial Results, August 6, 2026; Cloudflare Blog, "Cloudflare outage on November 18, 2025."