Uptime Monitoring with Edge and Origin Checks
Two servers check every URL every 10 minutes, through your CDN and, if you add the IP, straight at your origin.
Trusted by market leaders · Client results
What a monitor checks
A monitor is one URL. Every 10 minutes it gets a GET request, from 51.195.222.219 and 51.195.222.220 in turn. Up means the final response is a 200 after redirects. Each check stores the status code, TTFB, total time, the number of redirects, the cache status your CDN sends back and the expiry date of the certificate.
A monitor goes Down after two failed checks in a row. The servers take turns, so two failures in a row means both of them saw it. A single timeout from one server shows as Failing, one red bar in the list, and the next good check clears it.
A check fails when there is no answer within 30 seconds, when DNS or TLS fails, or when the server answers with a 5xx. A 403, a 429 or a Cloudflare challenge is Blocked. Any other status is Unexpected status. Neither of those counts as downtime: the site answers, it just doesn't answer the way it should.
Your CDN can hide an outage
Cloudflare keeps serving cached pages when your origin goes down. With Always Online it does that on purpose. A check on the public URL gets a 200 with cf-cache-status: HIT and reports Up, while every logged-in user, every cart and every page that wasn't in the cache gets a 5xx.
The origin check goes around DNS and the CDN. It connects to the IP of your server, with your hostname in SNI and in the Host header, the same way curl --resolve does. When the edge answers 200 and the origin times out, the monitor is Down and says why.
Origins behind Cloudflare often have a Cloudflare Origin CA certificate, which browsers don't trust. The origin check reads that certificate but doesn't fail on it. If the IP you enter answers with Cloudflare headers, the monitor tells you: that IP is not your origin.
The origin IP stays in the monitor's settings. It is never shown in the monitor list, in API lists or in answers to an AI agent over MCP. For some sites a hidden origin is part of their security, so it stays hidden here too.
Checker TTFB next to the TTFB of your visitors
Link a monitor to a RUM project and its page shows the checker's TTFB next to the TTFB p75 of your real users. They measure different things. The checker makes one request from a data center, on a fast line, without cookies. RUM TTFB adds the visitor's network, DNS on a phone, redirects and every page your CDN didn't have in cache.
On acme-slowserver.com the checker needs about 950 ms, and close to 1.4 s every evening. The TTFB p75 of its real users is 1.92 s. When a single request from a data center already takes close to a second, the server builds every page from scratch. Start with page caching on the server. A CDN only helps for pages it is allowed to cache, and the cart and account pages are never among them.
A release that breaks one page
Add the pages that make money as monitors too: the checkout, the login page, your busiest product page. On acme-shop.com the checkout answers 404 since a release two days ago. The homepage is fine. The monitor shows Unexpected status from the first check after the release.
If a URL should answer with something else, a 301 for example, set the status that counts as up under Advanced.
Certificates that don't renew
Every HTTPS check reads the certificate. The monitor list counts certificates that expire within 14 days, and the monitor page shows the days left. Certbot renews 30 days before expiry, so a certificate with 9 days left means renewal has been failing for three weeks. The usual reasons: a firewall rule that closes port 80, a DNS change, a site moved to a new server.
When the checker gets blocked
Bot protection blocks unknown visitors from data centers, and the checker is one of them. Cloudflare Bot Fight Mode and Wordfence do it most often. The monitor then shows Blocked, so a firewall rule never looks like an outage. Let the uptime checker through your firewall shows the rule for Cloudflare and Wordfence, and how to use a request header.
API and MCP
Monitors work through the same API keys as your RUM data. List, add, change and delete them over REST, or ask for a check right away. The MCP server has the same actions as tools, so Claude can answer "was acme-cdnmask.com down this week, and since when?" from the stored checks. The endpoints and tools are in the uptime API reference.
What it doesn't do
- A check every 10 minutes means an outage of five minutes can fall between two checks. Downtime shows as "down since at least 21:10", never as an exact minute.
- Down alerts by email and Slack are not there yet. For now the monitor list and the API show the state.
- It checks the HTML response of a URL. Whether your JavaScript, your images or the CoreDash script load is not part of it; that is what RUM is for.
Add a monitor
- In CoreDash, open Uptime monitors under Monitoring.
- Click Add monitor and enter the URL. Link it to a RUM project if you want the TTFB comparison.
- Under Advanced, add the origin IP, a request header for your firewall rule, or a different status that counts as up.
- The first check runs within a minute.
