Back to blog
2 min read
IncidentsUptime monitoring

When a CDN outage is your outage (even if origin is fine)

Customers do not care that your origin returned 200 on a private path. If the CDN is how they reach you, its bad day is your incident.

NK

Nabin Khair

Founder

The classic trap: curl the origin IP from a bastion, get 200, declare "not us," while the world hits https://app.you.com through a CDN that is melting. From the customer's chair, you are down.

What to monitor

Point external checks at the public hostname: the same one in marketing and apps. That path includes DNS, TLS on the edge, CDN config, and WAF. Origin-only checks are useful as a second signal, not the only one.

If public is red and origin is green, you have classified the problem in one step.

How to talk about it

On the status page, "CDN provider experiencing issues; we are routing where possible" is honest. "Everything is fine" because origin metrics are calm is not. See degraded when some regions or POPs fail.

Runbook crumbs

  • Link to Cloudflare / Fastly / CloudFront status (whatever you use)
  • How to bypass or fail open if you have a documented emergency path
  • Who can change DNS / cache settings

Do not invent a bypass under pressure if you never practiced it (alert drills).

Multi-region reads

Edge problems are often regional. Everyone vs just me applies: some monitor regions may fail while others pass. That pattern is a clue, not a reason to ignore the red ones.

Ownership

You chose the CDN. Its outage is your communication problem and often your mitigation problem. Blame can wait for the postmortem. During the incident, customers need your voice on your status URL, hosted off your app, still reachable when origin is sad.

Keep reading

More from the Tallwatch blog

More on monitoring, alerting, and status pages.