Production domain
Monitor the canonical domain. Cloudflare Pages itself is rarely the failure point — the more common failures are at the Cloudflare account level (rules, page rules, WAF, redirects).
Cloudflare Pages sits behind Cloudflare's edge network, which means most of your monitoring concerns are about edge config and cache headers rather than origin health. The site itself is hard to take down; the more common failure mode is misconfigured edge rules.
Monitor the canonical domain. Cloudflare Pages itself is rarely the failure point — the more common failures are at the Cloudflare account level (rules, page rules, WAF, redirects).
If you use Workers for API routes or edge logic, monitor the Worker route directly. They have their own failure modes (CPU limits, memory exhaustion) that the static site won't show.
If your Pages project pulls from a custom origin, monitor the origin separately. Cloudflare will serve cached content even when origin is dead — your customers don't see the outage until cache expires, and we won't see it through the cached front.
If you've enabled aggressive 'Under Attack' mode or strict bot fight mode, our user-agent may get challenged. Add an allowlist rule for our user-agent string (web-down/1.0) or our IP if needed.
Cloudflare's edge cache means your monitor may keep showing 200 OK even when your underlying origin (if any) is broken. For accurate origin monitoring, set up a separate monitor that bypasses cache (use a query param like ?cachebust=true).
Tiered cache means our 5-minute checks may all hit the same cached object. That's actually fine for uptime monitoring — but it means a cache poisoning incident wouldn't be detected by us. Out of scope for what we monitor.