HTTP Uptime Check: a beginner's guide
Check if a URL responds, measure status, timing, and payload size
HTTP uptime checks: proving a web service is actually serving, not just reachable
An HTTP uptime check is a single HTTP(S) request to a URL that measures whether the web service at the other end is up, how fast it responded, and what it served back. Unlike a ping (which only proves the host is reachable at the network layer using the ICMP protocol), an HTTP check proves the actual web service is alive and answering requests. The check issues a `HEAD` or `GET` to the target URL, waits up to a configurable timeout for a response, and reports the HTTP status code, the timing broken into time-to-first-byte and download phases, the size of the response body, any redirect chain that was followed, and — for HTTPS URLs — whether the TLS handshake completed. Non-2xx status codes and network errors are reported as data, not as hard errors.
You should care because "is the site up?" is the single most common question in operations, and it has no honest answer from network-layer tools alone. A server can respond to ping just fine while the web process is crashed, the load balancer is misrouting, the TLS certificate has expired, or the origin is serving a 502. The HTTP check is the smallest end-to-end probe that tells you whether the thing your users actually rely on — the web service — is functioning. It is the building block of every uptime monitor, every CI/CD smoke test, every post-deploy canary gate, and every third-party availability probe on the internet.
The five things every HTTP check measures:
Status code. 2xx means success; 3xx means a redirect; 4xx is client error; 5xx is server error. The status alone catches most outages.
Time to first byte (TTFB). How long from connection to the first byte of the response. This is the server's processing time, isolated from download time.
Total time. End-to-end time from request start to response complete. Includes DNS, TLS, TTFB, and download.
Content size. How many bytes the response body contained. A suddenly tiny payload can mean a broken template; a suddenly huge one can mean a leaked debug page.
Redirect chain. The full list of URLs hit if redirects were followed. Unexpected hops are a sign of misconfiguration.
Three questions an HTTP check answers:
Is this URL returning a successful response right now?
How long does it take end-to-end, and where in that time is the slowness?
Did a recent deploy change the response — different status, different size, new redirect?
The cost of relying on ping alone is false-positive "up" signals when the network is fine but the web service has silently broken. The fix is to probe the HTTP layer explicitly. Every uptime service — Pingdom, StatusCake, UptimeRobot, Cloudflare Health Checks — is built on exactly this primitive. The relevant protocol standards are RFC 9110 (HTTP semantics) and RFC 8446 (TLS 1.3).
The HTTP Uptime Check endpoint, in plain language
In one sentence: Check if a URL (web address) responds, measure status, timing, and payload size
Performs a single HTTP (HyperText Transfer Protocol)(S) request to a URL (web address) and reports status code, total response time, content size, redirect chain, and TLS (Transport Layer Security) handshake verification. Stateless — use this as an on-demand "is my site up?" probe rather than scheduled monitoring. Runs from the Cloudflare Workers network with edge cache bypassed so every check hits the origin.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Issues an HTTP (HyperText Transfer Protocol) HEAD (default) or GET request to the target URL (web address) with a configurable timeout and redirect policy. Returns the final status code, total response time, accurate content length (via streamed byte count on GET, or Content-Length header on HEAD), response headers (Content-Type, Server, Cache-Control), the full redirect chain, and — for HTTPS (secure HyperText Transfer Protocol) URLs — whether the TLS (Transport Layer Security) handshake completed successfully. Non-2xx responses and network failures are reported with status/error fields; only invalid input returns HTTP errors.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the HTTP Uptime Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Know in one call whether a URL (web address) is reachable, how fast it responds end-to-end, and whether it is serving the content you expect. Essential for post-deploy smoke tests, automated deployment workflows gating, third-party dependency health checks, and as a building block for custom monitoring dashboards. Distinct from ICMP (Internet Control Message Protocol) ping, which only proves a host is reachable at the network layer — an HTTP (HyperText Transfer Protocol) check proves the actual web service is serving requests.
Picture this in real life. Imagine a devops engineer. Here's the situation they're walking into: Immediately after a deploy, fire an HTTP (HyperText Transfer Protocol) check against canary URLs to confirm the new version returns 200 OK with expected response time before promoting traffic or firing downstream webhooks. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the HTTP Uptime Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the HTTP Uptime Check tool is built for you:
Where in the world is this server actually located, and who runs the network it sits on?
How fast does traffic move between my users and my service?
Is the IP address I am looking at part of a residential network, a data center, or something suspicious?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Network engineers, IT admins, sales teams qualifying enterprise prospects, and product teams building geo-personalization or fraud rules. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Without an HTTP (HyperText Transfer Protocol) check endpoint, you would only know your site is down when users report it — ICMP (Internet Control Message Protocol) ping proves the host is reachable but not that the web service is actually serving traffic. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the free plan. The technical details: `GET /v1/network/http-check`.
When would I actually use this?
If you're still on the fence about whether the HTTP Uptime Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a devops engineer, a backend engineer, and an SRE — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Post-Deploy Smoke Test
Imagine you're a devops engineer. Immediately after a deploy, fire an HTTP (HyperText Transfer Protocol) check against canary URLs to confirm the new version returns 200 OK with expected response time before promoting traffic or firing downstream webhooks.
Why it matters: Catch broken deploys in seconds instead of waiting for users or scheduled monitors to report outages.
Story 2: Third-Party API Availability Probe
Imagine you're a backend engineer. Before running a batch job that depends on an external API (Application Programming Interface), check that the API's health endpoint responds fast enough. Gate the job or switch to a fallback if timing or status is off.
Why it matters: Fail fast on upstream outages and avoid cascading failures in dependent workflows.
Story 3: Synthetic Monitoring Primitive
Imagine you're an SRE. Build custom uptime dashboards and alerts by polling this endpoint from a scheduler and pushing results to a metrics backend. Gives you status, response time, and content size without running your own probe infrastructure.
Why it matters: Skip the complexity of running monitoring agents — compose availability checks from a single API (Application Programming Interface) call.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the HTTP Uptime Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
When a customer reports that your site is slow specifically from their region.
When you need to know whether traffic is coming from a residential network or a data center.
When planning a CDN, points of presence, or geographic expansion.
During an outage, to see exactly where in the route packets are getting lost.
If you can see yourself in even one of those bullets, the HTTP Uptime Check tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the HTTP Uptime Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the HTTP Uptime Check tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/network/http-check?url=https%3A%2F%2Fexample.com"What you need to provide
You need to provide 5 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
url | string | Yes | URL (web address) to check. Accepts a full HTTP(s) URL, a bare hostname, or an IP (Internet Protocol address) address — "HTTP://" is added automatically if no scheme is present. Private IPs, cloud metadata hosts, and non-HTTP(s) schemes are rejected. | https://example.com |
method | string | Optional | HTTP (HyperText Transfer Protocol) method: "HEAD" (cheapest, no body) or "GET" (measures actual download size). Defaults to "HEAD". Allowed values: HEAD, GET | HEAD |
follow_redirects | boolean | Optional | Whether to follow 3xx redirects. When false, the first redirect response is returned as-is. Defaults to true. | true |
max_redirects | number | Optional | Maximum number of redirects to follow (0-10). Defaults to 5. | 5 |
timeout | number | Optional | Request timeout in milliseconds (1000-30000). Defaults to 10000. | 10000 |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
url | string | The URL (web address) that was checked (original, before redirects) |
final_url | string | The URL (web address) after following any redirects |
method | string | HTTP (HyperText Transfer Protocol) method used: "HEAD" or "GET" |
status.code | number | HTTP (HyperText Transfer Protocol) status code (e.g., 200, 404, 500). Null if the request never produced a response. |
status.ok | boolean | Whether the status code is in the 2xx range |
timings.total_ms | number | Total wall-clock time from request start to response fully received (ms) |
content_length_bytes | number | Actual downloaded body size in bytes for GET requests; Content-Length header value for HEAD. Null if unavailable. |
headers.content_type | string | Response Content-Type header (e.g., "text/html; charset=utf-8") |
headers.server | string | Response Server header, if present |
headers.cache_control | string | Response Cache-Control header, if present |
headers.content_length | string | Response Content-Length header, if present |
redirects | array | Chain of redirects followed. Each entry: { from, to, status }. |
ssl.verified | boolean | For HTTPS (secure HyperText Transfer Protocol) URLs: true if the TLS (Transport Layer Security) handshake succeeded. Null for plain HTTP:// URLs. |
error | string | Error label when the check failed: "timeout", "fetch_failed", "invalid_redirect_location" (the Location header could not be parsed as a URL (web address)), or an underlying error message. Null on success. |
checked_at | string | ISO-8601 timestamp of when the check started |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
API (Application Programming Interface) — A way for one program to ask another program for something — like a waiter taking your order to the kitchen.
URL (web address) — The full address of a page, like https://example.com/about.
HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.
HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.
TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.
ICMP (Internet Control Message Protocol) — The "knock-knock" of the internet. Tools like ping use it to check whether a server is reachable and how long the round trip takes.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.