Check if a website is down from Cloudflare's network

When a site “looks down,” the truth often depends on where you measure from. Your laptop, a single VPS, and Cloudflare’s edge can all disagree. Probing from Cloudflare’s network gives a view closer to how many users reach origins through the edge - and it is straightforward to expose as a small Worker API using the platform Fetch API.

This guide covers definitions of “down,” probe design, pairing diagnostics, scheduled alerts, and the Is It Down experiment you can deploy today.

Cloudflare products in this patternCopy Anchor Link

What “down” should meanCopy Anchor Link

Be explicit. For APIs and status tools, a useful definition is:

• DNS resolves (optional separate check)
• TCP/TLS succeeds
• An HTTP response returns within a timeout
• Optionally: status is not 5xx

A site can return 200 with a broken app, or 503 while intentionally in maintenance. Encode the policy in your JSON so clients do not guess.

Example success payload:

{
  "url": "https://example.com",
  "ok": true,
  "status": 200,
  "latencyMs": 142
}

Document redirect policy: follow or not, and max hops. Open redirects and file: schemes must be rejected by URL validation.

Edge probe architectureCopy Anchor Link

Client → Worker → timed fetch(url) → JSON { ok, status, latencyMs }

Worker responsibilities:

1. Validate url (http/https) with a shared helper
2. Time the request (performance marks or Date.now())
3. Catch network failures as structured errors (FETCH_ERROR)
4. Never follow redirects into private or non-http(s) schemes
5. Optionally attach probe colo from request.cf

Do not turn this into a full uptime SaaS on day one. Ship the probe, then add schedules and storage.

Pair diagnostics instead of one mega-endpointCopy Anchor Link

When an origin fails, operators want more than a boolean. Compose focused Cloudflare-backed experiments:

Wire them from a status page, chatops bot, or MCP tool. Each stays under ~60 seconds and single-purpose.

Scheduled monitoring with Cron TriggersCopy Anchor Link

Cron Triggers let a Worker run on a schedule without an external scheduler:

Cron → Worker scheduled handler → probe targets → write D1 → email on failure

That is the path Uptime Monitor Alerts demonstrates. Use the one-shot Is It Down API for ad-hoc checks and agent tools; use cron when you need history and pages.

Operational cautionsCopy Anchor Link

• Respect robots and ToS for third-party targets; this is a diagnostic tool, not a scraper
• Rate-limit public deployments - open probes get abused as free scanners
• Timeouts beat hanging Workers; fail with FETCH_ERROR
• One colo ≠ global truth - a single Worker invocation runs in one location; sample multiple regions if you need that story
• TLS and SNI - some failures are certificate issues; pair with an SSL inspector experiment when needed

Error codes worth standardizingCopy Anchor Link

Keep codes stable so dashboards and agents can branch without scraping English messages.

Deploy and verifyCopy Anchor Link

1. Read Workers Fetch once for semantics (redirects, cf properties)
2. Deploy Is It Down
3. Call it with a known-good URL and a known-bad host
4. Confirm JSON error codes for invalid input
5. Graduate to Uptime Monitor Alerts when you need cron + history

You get a tested reachability Worker with the same error conventions as the rest of the catalog - ready to embed in bigger monitoring flows built on Cloudflare products rather than a random VPS cron.

Production checklistCopy Anchor Link

1. Define “down” in writing (status codes, timeouts, redirect policy).
2. Separate ad-hoc probes (Is It Down) from scheduled monitors (Uptime Monitor Alerts + Cron Triggers).
3. Store history in D1 if humans need trends.
4. Alert via email/webhook - avoid paging on single blips; require N failures.
5. Rate-limit public probe APIs.
6. Pair with DNS and header inspectors before declaring “origin broken.”

Multi-region truthCopy Anchor Link

A single Worker invocation sees one colo. If you need “down globally,” sample multiple regions or accept that your probe is “down from Cloudflare’s network in colo X.” Document that limitation next to the green/red badge.

FAQCopy Anchor Link

Is this a replacement for paid uptime SaaS?Copy Anchor Link

It is a building block. You own alerting, multi-region sampling, and SLAs. Many teams start here then graduate complexity only where needed.

Can I probe internal hosts?Copy Anchor Link

Only if the Worker can reach them (public internet or appropriately configured tunnels/services). Private RFC1918 targets usually fail from the public edge.