API monitoring
Watch JSON endpoints, status codes, and response times.
What it watches
An API monitor parses the JSON your endpoint returns and asserts on a field inside it. Not the status line, not the raw text: the value at a path you name.
That matters because a health endpoint's whole job is to answer a question, and 200 is not the answer. {"status":"degraded"} ships with a 200. So does {"db":false}. An API check reads the thing your endpoint went to the trouble of telling you.
Assert on a path, not a substring
A rule names a dot path and, optionally, the value you expect there: status equals ok, checks.db equals true. Omit the expected value and the rule becomes a presence check, which passes as long as the field exists at all.
This is what separates an API check from a keyword one. Keyword asks whether the text ok appears anywhere in the body, which a field called not_ok would satisfy. API asks what status is.
Unparseable is a failure, not a mystery
When the body isn't JSON, the check fails and says so rather than guessing. An HTML error page where JSON should be is exactly the outage you want caught, and it's a distinct verdict from "the field was missing" and from "the field said something else".
Each of those three reads differently in the incident: not JSON, missing, or the value it got instead.
Name the field that matters
Point it at an endpoint that answers in JSON, then say what to assert. Every rule has to pass, and read-only methods still apply: GET is the default, and HEAD isn't offered, because a body is the entire point.
curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{
"type": "api",
"url": "https://example.com/health",
"content_rules": [{ "type": "json_field", "path": "status", "equals": "ok" }]
}'Tune it when the defaults aren't right
Highlighted is the default.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Every outage,
written down as it happens.
A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.