Between August 7 and August 14, Cloudflare's status page logged thirteen separate incidents. Not one giant outage, thirteen distinct events in eight days, touching R2 object storage, Durable Objects, Workers KV, Workers AI, Magic Transit, and regional traffic across four continents. For teams doing edge outage response, this cluster is a better teaching case than any single mega incident, because it shows what failure at the edge actually looks like now: partial, regional, layered, and relentless. This post walks through what happened, why edge failures behave differently from origin failures, and how to build an on-call practice that handles a provider having a bad week rather than a bad hour.

What actually happened during Cloudflare's eight day incident cluster

The sequence started on August 7 with an R2 storage failure in Cloudflare's Eastern North America region and stretched through a Durable Objects and Workflows availability drop on August 14, as documented in coverage of the cluster and on Cloudflare's own status history. In between, customers hit 503 errors 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.

Individually, most of these were minor. A few lasted under an hour. Some touched only one product in one region. That is exactly why the cluster matters: almost none of these incidents would have crossed the alerting thresholds most teams run, yet a customer in Bangkok hitting 5xx errors on your site does not care that your global error rate stayed under one percent.

The concentration question underneath it

Cloudflare sits in front of roughly a fifth of the web's traffic. When a provider at that scale has thirteen incidents in eight days, the question for engineering teams is not whether Cloudflare is good at reliability. By any historical standard it is. The question is what your architecture and your on-call process assume about the layer between your origin and your users, because most teams assume it simply works, and they instrument everything except it.

Why this was not one story but thirteen

It is tempting to read a cluster like this as one systemic failure. The evidence does not support that. R2 availability, Workers KV errors, a portal authentication failure, and a Jakarta traffic spike are different failure domains with different causes. What they share is the week they happened in and the dashboard they appeared on. That distinction matters for response: a team that treats an incident cluster as one ongoing mega incident burns out its responders and muddles its timelines. A team that treats each event as isolated misses the aggregate pattern. You need both views, and most incident tooling gives you neither.

Why edge outage response differs from origin outage response

When your own service falls over, you own the fix. When your edge provider degrades, you own the impact but not the remediation, and that changes the entire shape of the response.

You cannot fix it, so the job is containment

During an origin incident the on-call engineer's job is diagnosis and repair. During an edge incident the job is different: confirm the fault is upstream, communicate to stakeholders, and decide whether to route around it. Those are three distinct tasks, and none of them is "fix the bug." Teams that have not internalized this waste the first twenty minutes of every edge incident trying to debug their own healthy code, because that is what their runbooks assume.

Detection is harder because the failure is between you and your users

Your origin metrics look clean during an edge incident. CPU is fine, database is fine, your health checks (which usually run inside your own network) are green. The failure lives on the path between the edge PoP and the user. If you do not run synthetic probes from outside your own infrastructure, from the regions your users are actually in, you find out about edge incidents from support tickets. During the August cluster, the regional spikes in Kuwait, Bangkok, Jakarta, and Dammam were precisely the kind of failure that origin-side monitoring structurally cannot see.

Status pages lag reality

Provider status pages update when a human at the provider decides an incident is confirmed and customer visible. That can trail first impact by fifteen minutes or more, which in a short regional incident is the entire incident. Your own external probes will beat the status page nearly every time. Treat the status page as confirmation, not detection.

Building an on-call practice for a provider's bad week

A single outage tests your escalation policy. A thirteen incident week tests things most teams have never thought about: pager fatigue budgets, incident deduplication, and when to stop treating each event as novel.

Deduplicate before you page

If your alerting fires a fresh page for every upstream blip during a cluster week, your on-call engineer gets thirteen adrenaline spikes in eight days and starts sleeping through pages by day five. Alert fatigue is not a moral failing, it is a rate problem. Group related upstream alerts into a single tracked issue that accumulates events rather than spawning new pages. The first R2 incident deserves a page. The fourth R2 related blip in the same week deserves an append to an existing thread and a daily summary.

Run a provider incident log, not just an incident log

Most teams log their own incidents and let provider incidents evaporate. During the August cluster, the teams that could answer "how many times has Cloudflare degraded this month, and which products" from their own records were the ones able to make an evidence based call about architectural changes. Keep it lightweight: one line per event with date, provider, product, region, duration, and whether your users noticed. The pattern is the payload. Thirteen lines in eight days is an architectural signal that no single line conveys.

Decide your failover posture in advance

Multi CDN and multi edge setups exist, but they are expensive and operationally heavy, and for most teams they are overkill. What every team should have is a decision, made calmly in advance, about what they will do when the edge degrades: serve stale from an origin cache, fail over DNS to a secondary path, or consciously ride it out. Riding it out is a legitimate strategy for short incidents. What is not legitimate is debating the options live at 3 a.m. while the incident is running. Write the decision tree down, put thresholds on it (degradation type, region, expected duration), and rehearse it once.

Practice the "is it us or is it them" drill

The single most valuable capability during an edge incident is answering "us or them" in under two minutes. That requires three things ready before the incident: external synthetic checks against your user facing endpoints from multiple regions, a dashboard that shows your origin health next to provider status in one view, and a recent deploy log in the same place. Teams with those three answer the question instantly. Teams without them spend the whole incident window arguing about it in a channel.

What to instrument so regional edge failures stop being invisible

The August cluster's regional spikes are the hardest failure class to catch, so they are worth specific instrumentation advice.

Probe from where your users are. Synthetic checks from three to five regions that matter to your business, hitting real user journeys through the edge, not origin IPs directly. A probe that bypasses the CDN tests the wrong thing.
Break error dashboards down by region and PoP. A global aggregate hid every single one of the Kuwait, Bangkok, Jakarta, and Dammam spikes. Per region panels make them obvious in seconds.
Alert on divergence, not just absolutes. If Jakarta's error rate is ten times the global median, that is a signal even when the absolute number looks small. Divergence alerts catch regional failures that absolute thresholds never will.
Subscribe to provider status programmatically. Pipe status feed changes into the team channel automatically, tagged to the tracked issue if one is open. Confirmation should arrive without anyone refreshing a status page.
Record the all clear separately from the fix. Edge incidents often have a tail: routes reconverge, caches refill, retries drain. Mark impact end when your probes go green, not when the provider says resolved.

A worked example: one regional spike, start to finish

Abstract playbooks are easy to nod along to, so here is the concrete version. Imagine the Jakarta 5xx spike from the August cluster hitting a team that sells into Southeast Asia, walked through minute by minute.

Minute zero to two: detection and the first decision

A synthetic probe running from a Jakarta vantage point fails twice in a row on the checkout journey while probes from Frankfurt and Virginia stay green. That divergence, regional failure with global health, is itself the diagnosis: this is almost certainly not your origin. The alert posts to the on-call channel with the probe results attached. Because it is a single region and revenue exposure there is moderate, the routing rule posts it as a channel alert rather than a phone page. Nobody is woken up for this one, and that was a decision made months ago, not tonight.

Minute two to ten: confirmation and communication

Whoever is active acknowledges the thread. The combined health dashboard shows origin metrics flat and normal, the deploy log shows nothing shipped in six hours, and the provider status feed has nothing yet, which is expected since status pages lag. The engineer replies to the thread with a one line assessment: regional edge degradation, Jakarta, us-or-them says them, monitoring. Support gets a heads up in their channel so the first customer ticket from Indonesia does not start a duplicate investigation. Total elapsed effort: one engineer, a few minutes, no bridge call.

Minute ten to resolution: the tail and the record

Twenty minutes later Cloudflare's status page confirms a regional issue, which validates the call without having changed it. The probes go green at minute thirty four, and impact end is recorded from the probe timestamp, not the provider's later "resolved" stamp. The thread gets tagged to the week's provider issue, adding one line to the provider log: date, product, region, thirty four minutes, customers noticed (two tickets). The whole event consumed perhaps fifteen minutes of human attention. Multiply that discipline across thirteen events in eight days and the difference between this team and one improvising every event is roughly a full engineer day of attention, plus the sleep nobody lost.

What the example assumes you built beforehand

Every calm minute in that walkthrough was purchased in advance: the regional probes, the divergence alert, the routing rule that distinguishes page from post, the combined dashboard, the provider log, and the shared understanding that "them" incidents get containment rather than heroics. None of these are expensive. All of them fail to exist by default.

Counting provider pain in your error budget

One more discipline separates teams that learn from cluster weeks from teams that merely survive them: accounting. If your service level objectives silently absorb provider incidents, you are hiding real user pain from your own decision making. When Cloudflare's December 2025 outage writeup circulated, plenty of teams discovered they could not say how much of their own error budget that event had consumed, because their SLO math did not attribute burn to causes.

The fix is cheap: tag error budget burn with a cause label, yours versus upstream, at incident close. Over a quarter this yields the number that actually drives architecture decisions, which is how much availability you are losing to layers you do not control. If upstream burn is a rounding error, your single provider bet is fine and the multi CDN pitch deck can stay in the drawer. If upstream burn is eating a third of your budget, you now have a business case stated in the only currency that matters, user facing availability, rather than in vibes about a bad week. Either way the decision gets made on recorded evidence, which is precisely what a provider incident log plus tagged burn gives you and what a stressful week's fading memories do not.

How Slack native on-call changes the math during cluster weeks

A week with thirteen upstream events is a communication problem more than an engineering problem. Every event needs a quick triage, a routing decision, and a record, and almost none of them need a war room. This is where tooling that lives in chat earns its keep.

With a Slack native setup like Pagerly, the triage loop for an upstream blip collapses to its minimum: the alert lands in the channel, the on-call engineer acknowledges it in one tap, tags it against the open provider issue, and moves on. No console to open, no separate incident record to write later, because the thread is the record. Schedules and escalation live in the same place, so when the fourth blip of the week lands at 2 a.m., whether it pages a human or just appends to the thread is a routing rule, not a judgment call made by a tired engineer.

The aggregate view matters too. Because every provider event of the week sits in threads in one channel, the Friday review of "what did Cloudflare do to us this week" is a scroll, not an archaeology project across an incident tool, a monitoring tool, and someone's memory. For the pattern driven decisions that clusters demand, cheap aggregation is the feature that matters most.

Takeaways: edge outage response in five decisions

The August cluster will not be the last of its kind. Edge providers run enormous, fast changing platforms, and the incident pattern across the industry this year points the same way: more events, shorter durations, narrower blast radii. Here is the short list worth acting on:

Instrument the path, not just the origin. External regional probes and per region dashboards are the price of seeing edge failures at all.
Deduplicate upstream alerts into tracked issues. Protect your responders' attention during cluster weeks; page on the first event, append on the rest.
Keep a provider incident log. Thirteen one line entries are an architectural argument. Zero entries are amnesia.
Pre decide your failover posture. Serve stale, fail over, or ride it out: a written decision tree with thresholds, rehearsed once, beats any 3 a.m. debate.
Make "us or them" a two minute question. External probes, a combined health view, and the deploy log in one place.

None of this requires abandoning your edge provider or building a second internet. Cloudflare had a bad week; every provider eventually does. The teams that came through the cluster calmly were not the ones with the most redundancy, they were the ones whose on-call process assumed upstream failure was normal, detected it from the user's side, and had already decided what to do about it. That is an achievable standard for any team, and a week like August 7 to 14 is the best argument for getting there before the next one.