API

An API monitor makes a real HTTP request to your endpoint and validates the response, not just that it answered. It's a full HTTP monitor — SSL, timing breakdown, redirects, auth, HTTP/3 — with a response-validation engine on top: assert on any JSON field, header or body text, and extract numbers from the body to chart and alert on.

HTTP monitor vs. API monitor. The HTTP monitor answers "is it up?". The API monitor answers "is the response correct?" — because an endpoint can return 200 OK and still be wrong.

When to use it

Reach for an API monitor when the contents of the response matter:

• A health endpoint returning {"status":"ok"} — alert if the field is ever anything else, even though HTTP still answers 200.
• A JSON API where a field flipping ("degraded", false, an empty list) is an outage the status code won't reveal.
• A value you want to watch over time — queue depth, active users, a price, rate-limit remaining — pulled out of the response and charted.

For a simple "is my site up + optional keyword" check, the HTTP monitor is lighter.

Build it live — Run & inspect

You don't have to type JSONPaths blind. In the monitor's Settings, the Try it section runs the request once from a real monitoring probe and shows you the actual response:

1. Fill in the URL (and method / headers / auth if needed).
2. Click Run request.
3. You get the live response — status, timing, size, headers and the body as a list of fields (resources.core.remaining = 60, …).
4. Click Extract on any number to chart it, or Assert to pin it — the JSONPath is filled in for you, no typing.

Because it runs through the same prober and engine a scheduled check uses, what you see in Run & inspect is exactly what the monitor will do.

The request

Configure the call WatchFor makes on every check:

• Method — GET, POST, PUT, PATCH, DELETE, HEAD.
• Headers — any custom headers (e.g. an API key). One click adds a no-cache bundle so a CDN can't serve you a stale response.
• Body — a request body (works even on GET, for Elasticsearch-style APIs).
• Auth — Basic, Digest or Bearer token, stored encrypted at rest.
• Transport — Auto (TCP with HTTP/3 fallback), or force TCP / HTTP/3.

Response assertions

Assertions validate the content of the response. Each is a row:

Sources: JSON body, header, response text. Operators: equals, not equals, greater/less than (and or-equal), contains, does not contain, is one of, is not one of, exists, does not exist, matches regex.

JSONPath uses dot/bracket syntax — data.items.0.name, data.#(active==true).id. A leading $. (Checkly-style) is accepted, so paths you already have paste straight in.

A failing assertion raises the Assertions Failed alert (enable it in the Alerting tab). The detail page and each check's View response dialog show every assertion pass or fail with expected vs. actual — when a check goes red you see exactly which rule broke and what the API returned.

Status code, response time and SSL are not assertions. They're evaluated on the Alerting tab (see below) — the same place, and the same friendly controls, as every other monitor type. Assertions here are just for the response content.

Extract values — chart & alert

This is what sets the API monitor apart. Point a JSONPath at a numeric field and name it:

active_users   ←  data.metrics.active_users
queue_depth    ←  data.queue.depth
rate_remaining ←  resources.core.remaining

Each becomes a metric, stored on every check:

• Charted over time on the detail page. Every value gets its own chart on its own scale, so a huge number (a reset timestamp of 1786203625) never flattens a small one (used = 0) the way a shared axis would.
• Alertable on a threshold, just like response time — e.g. queue_depth > 1000 (warning) and > 5000 (critical). One extraction, as many alert rules as you like.

Booleans map to 1/0, so a {"healthy": true} flag charts and alerts too. This is a time-series pulled straight out of your API — watch a value trend and get paged before it hits the wall, not just pass/fail.

Numbers → extract; text/structure → assert. For a numeric value you want to trend, extract it (chart + graduated thresholds). For an existence, string or structural check, use an assertion.

What else it captures

Because it's a full HTTP monitor, every check also records:

• SSL certificate — days until expiry, issuer, TLS version.
• Timing breakdown — DNS, connect, TLS handshake, time-to-first-byte.
• Response size — shown per check in the Probes tab, next to duration.
• Redirects, final URL, HTTP protocol version, HTTP/3 advertisement and legacy-TLS detection.

The Probes tab lists every check per region, and View response opens the full captured body, that check's assertion outcomes and extracted values.

Up / down and alerting

For an API monitor, success = the endpoint answered (a response came back). Everything else is an alert rule on the Alerting tab, so each failure gets its own descriptive incident — mirroring the HTTP monitor:

• Probe Status — no HTTP response at all (DNS, connection, TLS, timeout).
• HTTP Status Evaluation — status outside the allowed classes. A friendly 2xx / 3xx group picker, not a typed value.
• Assertions Failed — any response-content assertion failed.
• Response Time — latency over a threshold (warning + critical).
• SSL Certificate — certificate nearing expiry.
• Extracted value — any threshold on a value you extracted.

So a 500 fires "Unexpected HTTP status", a wrong JSON field fires "Response assertion failed", and a real outage fires "Endpoint unreachable" — never the wrong one. Alerts are confirmed across regions before firing. See Alerting for how rules and notifications work.

Example: monitor a rate-limit endpoint

https://api.github.com/rate_limit returns:

{ "resources": { "core": { "limit": 60, "remaining": 60, "reset": 1786203625, "used": 0 } } }

A useful setup:

1. Run & inspect → Run request, then click Extract on resources.core.remaining and resources.core.used.
2. On the Alerting tab, add HTTP Status Evaluation (accept 2xx) and an Extracted value rule: remaining < 10 → warning.
3. Save. The detail page now charts remaining and used over time, each on its own scale, and you get paged when you're about to run out of quota.