When the edge fails: detecting Cloudflare incidents early

Origin CPU is climbing and nobody has deployed anything. The on-call engineer scales the web tier up by half. It helps for about four minutes. Then the graph keeps climbing, as if the extra capacity was never added at all.

Nothing is wrong with the origin. The problem is that it is suddenly being asked to do several times its usual work. Cloudflare’s cache hit rate has fallen in one region, an edge incident, and traffic that was being served quietly at the edge is now arriving at the origin directly. The origin was never sized to be the cache.

Why it looks like a traffic spike

A CDN incident arrives at your origin disguised as a surge. Request volume jumps, latency rises, CPU saturates, and every instinct says "we are being hit harder than usual." The team reaches for the spike playbook: scale out, check for a bot attack, look for a campaign that drove unexpected traffic. None of it addresses the cause, because the visitor volume has not actually changed. Only where the requests are being answered has.

1. 11:02Edge cache hit rate in the EU drops from 94% to 61%
2. 11:04Origin request volume and CPU begin climbing
3. 11:07On-call scales the web tier; relief for a few minutes
4. 11:12Origin saturates again; response times rising
5. 11:19Provider status still green; team suspects a bot surge
6. 11:26Cloudflare posts "investigating elevated edge errors"

By the time the status page confirms it, the team has scaled twice, ruled out a deploy, and started chasing a bot attack that does not exist. The provider acknowledgement, as usual, trails the impact by a comfortable margin.

A CDN incident reaches your origin disguised as a traffic spike, and the spike playbook makes it worse.

Why scaling does not fix it

You can outrun a cache-miss surge with enough origin capacity, briefly, and at cost. But you are paying to do work the edge is supposed to absorb, and if the hit rate keeps falling, no amount of scaling stays ahead of it. The fix is not capacity. It is recognising that the origin is healthy and the edge is not.

What monitoring changes

Cache hit rate is an operational metric, not a performance footnote. Watching it, alongside the provider’s status feed, turns an unexplained origin surge into a one-line diagnosis: the edge stopped serving, so the origin started drowning. That reframing is the difference between scaling blindly and waiting out a provider incident you cannot fix but can at least name.

Crowswatch pulls Cloudflare incidents from their status infrastructure and surfaces them next to your own signals, so an edge problem reads as an edge problem before the second scale-up.