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.
