API monitoring
What an API monitor has to check that an uptime monitor doesn't, and how to run one: a path, a method, the headers it needs, the status it should return, the text its body should carry, and how fast — every five minutes, from outside.
$10/month base · $1 per hostname · HTTP options included
API monitoring judges the answer, not just the presence of one
API monitoring means calling an endpoint on a schedule, from outside, with the request a real client would send, and checking that the response is the one a healthy service gives: the right status code, the right content, within the time clients will wait. It exists because an API can be reachable and wrong at the same time — answering 200 with an error in the body, redirecting to a login page, or taking four seconds to say yes — and none of that shows up on a check that only asks whether the host answered.
Uptime monitoring is the necessary first layer: is the hostname resolving, is the certificate valid, is something listening on 443, does the homepage come back. API monitoring is the layer above it, aimed at the endpoints that do the work. The two are usually run by the same tool on the same hostname, five minutes apart, and the difference between them is entirely in how much the check is told to expect.
Four things an API check has to look at
Each one catches a failure the others miss. A monitor that can only do the first is an uptime monitor with a longer path.
The status code, exactly
A homepage that answers 200 is up. An API endpoint that answers 200 with an error object in the body, or 302 to a login page, is not. API monitoring names the status it expects — 200, or 204, or 401 for an endpoint that should refuse anonymous callers — and treats anything else as a failure, rather than lumping every 2xx and 3xx together.
Something in the body
A health endpoint that returns 200 while reporting a failed dependency inside its JSON is the most common way an API lies. Checking the body for a phrase the healthy response always contains — "status":"ok", a version string, a known field — catches the case the status code hides.
How long it took
Latency is the outage that arrives gradually. An endpoint that answers in 4 seconds instead of 200 milliseconds is technically up and practically broken for every client with a timeout. A response-time limit turns that into an alert with its own name, separate from downtime.
With the right request
Most endpoints worth monitoring need a token, an API key, or a tenant header to answer at all, and some need a method other than GET. A monitor that can't send an Authorization header can only watch the endpoints that don't matter.
The uptime check, told what to expect
There is no separate API monitor to buy or configure. Every hostname's uptime check takes HTTP options, and setting them is what turns it into an API check.
- 01
Add the hostname, then open the uptime check's options
The API's hostname is a website like any other — api.example.com gets uptime, SSL, DNS and domain checks the moment it is added. The uptime check then takes HTTP options: the path, the method, the headers it should send, what counts as up, and how fast the answer has to be. Set them once from the dashboard, the API, or the MCP server.
- 02
Every 5 minutes, the request you described
A real request from Cloudflare's network with a 10-second timeout: your method, your path, your headers. The status code is compared with the list you gave, the body is read only when you named text to look for and never on a 5xx, and the time to the response is compared with your limit. Redirects are followed and the final URL is recorded.
- 03
A failure is confirmed, then it alerts by name
A wrong status, missing body text, an unreachable host or a response over the limit fails the probe. One failing probe starts the clock; a second, five minutes later, confirms it and fires your uptime rules — downtime for the first three, a separate slow-response trigger for the last — to email, Slack, Discord, Microsoft Teams, or a webhook. A recovery alert follows once it passes again.
Six settings, all optional, all on the same probe
Leave every option empty and the uptime check is the plain probe it always was: a GET of the homepage, 2xx and 3xx up, 4xx a warning, 5xx down. Set a path and an expected status and it is a health check. Add a header and it is an authenticated one. Add body text and a limit and it is the check most API monitoring tools sell as a separate product.
Every probe records the status, the response time, the final URL after redirects, the method it used and whether the body text was found, so a failure alert can say exactly which expectation broke.
Down and slow are different alerts
An uptime rule carries three triggers. Downtime fires when the endpoint is unreachable, answers the wrong status, or is missing the body text, and the alert names which. Slow response fires when the endpoint answers correctly but over its limit, quoting the time and the limit. Recovery fires once a confirmed failure of either kind passes again. Each is confirmed by a second probe before it sends.
Rules route to email, Slack, Discord, Microsoft Teams, or a webhook, where an alert arrives as a structured http.alert event carrying http_down, http_slow, or recovered, so an on-call tool can page for the first and open a ticket for the second.
What people set the options for
A health endpoint
GET /api/health, expect 200, body must contain "ok". The three settings that turn a page-is-there check into a the-service-works check, for any framework that ships a health route.
An authenticated endpoint
Send Authorization: Bearer with a key scoped to monitoring and expect 200 from an endpoint anonymous callers can't reach. The check proves the token path works end to end, not just that the load balancer answers.
An endpoint that should refuse you
GET /admin with no credentials, expect 401 or 403. Monitoring in the other direction: the day that endpoint answers 200 to nobody is the day you want the alert.
A latency budget
GET /v1/search with a 1,500ms limit. Downtime is rare; a slow week that nobody measured is not. The slow-response trigger gives it a name and a time it started.
A third-party API you depend on
The payment provider's status endpoint, the auth service, the geocoder — with their public health paths and the headers they need. A vendor incident becomes your alert minutes before it becomes your support queue.
A GraphQL endpoint
POST /graphql, expect 200 — or, for a server that answers GET with a ready check, GET /graphql?query={__typename} with the body expected to contain __typename.
A service that doesn't speak HTTP — a database, a message broker, SSH — wants the port check instead: a TCP connect every five minutes, no protocol required.
What this API monitoring is not
Not multi-location
Every probe comes from Cloudflare's network, from one place. An endpoint that is slow only from one continent, or blocked only for one region, looks fine here.
Not a JSON assertion engine
The body check is a text match, not a query into the response. It can confirm "status":"ok" is present; it can't confirm that queue_depth is under 100. Endpoints that report health as numbers want a different tool.
Not a multi-step flow
One request, one response. Logging in, then calling an endpoint with the session, then checking the result is a browser or transaction check, which Upcheck does not run.
Not a request body
POST is sent with headers and no body. An endpoint that needs a JSON payload to answer usefully needs a dedicated test client, not a monitor.
Included in the dollar
$10 per month for the workspace, plus $1 per hostname per month — and the dollar covers everything Upcheck watches on that hostname: the uptime check every 5 minutes with whatever HTTP options you set, the SSL certificate every 12 hours, DNS every 6, the domain registration daily, and the keyword, page change and port checks once you set them up. An API with three hostnames is three dollars. A workspace can track up to 500.
Running a SaaS with an app, an API and a docs host? The SaaS monitoring page covers how the checks fit together across every hostname you ship.
Frequently asked questions
What is API monitoring?
API monitoring is the practice of calling an API endpoint on a schedule, from outside the system, and checking that it answers correctly — the right status code, the right content in the body, within an acceptable time — with whatever headers or credentials a real client would send. It differs from uptime monitoring, which only asks whether a page answers, in that it judges the answer itself. The point is to learn that an API is broken from a monitor rather than from the first client it breaks.
How is API monitoring different from uptime monitoring?
Uptime monitoring asks whether a URL answers; API monitoring asks whether it answers correctly. A plain uptime check accepts any 2xx or 3xx and reads nothing; an API check names the status it expects, may require a phrase in the body, may send a token, and may set a response-time limit. On Upcheck they are the same check — the uptime check with HTTP options set — so every hostname gets both the plain probe and, where you want it, the stricter one.
Can it send an Authorization header or an API key?
Yes. Up to ten request headers go out with every probe — Authorization: Bearer, X-API-Key, Accept, a tenant header, whatever the endpoint needs. Header values are stored as given and shown to members of your organization who can see the website, so use a key scoped to health checks rather than a production credential. The probe sets its own User-Agent and Host and won't let those be overridden.
Can it check the contents of a JSON response?
As a text match, yes: name a phrase the healthy response always contains, such as "status":"ok" or a version field, and the check fails when it is missing. It doesn't parse the JSON or compare values, so it can confirm a field is present but not that a number is within a range. The match is case-insensitive and reads the first 2 MB of the body.
Does it measure latency?
Every probe records the time to the response, and you can set a limit in milliseconds. A response over the limit fails the probe the way a wrong status does — confirmed by a second probe, then alerted — but it fires a separate slow-response trigger rather than the downtime one, so the alert says slow, and so a rule can choose to hear about one and not the other.
Is a 401 or 404 treated as down?
Only if you say so. Without an expected-status list, 4xx is a warning — the server is alive and answering wrongly at that path — and only 5xx and an unreachable host count as down. With a list, anything not on it is down, which lets you monitor an endpoint that should answer 401 to anonymous callers and treat a 200 as the failure.
Can it send a POST with a JSON body?
It can send POST, with your headers, but with no request body. That reaches endpoints that refuse GET and health checks that are POST-only; it doesn't exercise an endpoint that needs a payload to do useful work. For those, a dedicated API test client on a schedule is the right tool.
How often does it run, and from where?
Every 5 minutes, from Cloudflare's network, with a 10-second timeout. A failure is confirmed by a second probe before anyone is alerted, so a single slow answer never pages anyone; a real failure alerts within ten minutes. Probes come from one location, so an endpoint that fails only for one region will not show up here.
Know the API is wrong before a client does.
Add the hostname, tell the uptime check what a healthy answer looks like, and let the probes ask every five minutes.