API monitoring with JSON assertions and request bodies

Start with an endpoint that tells the truth

The most valuable API monitor is not a call to your busiest endpoint; it is a call to a health route that checks what matters. A shallow route that returns {"ok":true} proves only that the process runs. A route that touches the database and the queue and reports each one separately gives you something to assert on:

{"status":"ok","database":"ok","queue":"ok","version":"4.12.1"}. With the JSON API monitor type you point at one value in that document, for example database, and name the value it must have. When the database connection dies, the route still answers 200, the JSON no longer matches, and the incident says exactly which value was wrong. Keep the route cheap and unauthenticated, or protected only by a secret header, so that monitoring does not become a source of load.

How the assertion is evaluated

The response body is parsed as JSON; if parsing fails the check fails with "Response is not valid JSON". Your path is then resolved: dots walk into objects, a number or [0] indexes arrays, and an optional leading $ is accepted, so status.database, $.status.database and items[0].id are all valid. A missing path fails with "JSON path not found". If you also give an expected value, the actual value must equal it. Strings compare case-insensitively, numbers and booleans compare by their text form (true, 42), and objects or arrays compare as JSON.

That is deliberately equality only. There is no "less than" or "contains" operator today. When you need a threshold, have the API compute the verdict and publish it as a value: queue_ok:true is easier to assert than queue_depth<100. If you give a path with no expected value, the check simply requires that the path exists.

Methods, bodies and credentials

Any of GET, HEAD, POST, PUT, PATCH and DELETE can be used. A request body is sent for everything except GET and HEAD, and if it starts with { or [ and you did not set a content type, it goes out as application/json. Authentication has two tiers. Basic auth is a field in the advanced section on every plan. Bearer tokens and API keys in headers need the Pro plan, because custom headers are a Pro feature; the editor tells you so rather than silently dropping them.

Be careful with methods that change data. A POST every minute is 1,440 writes a day, and a monitor that creates a record needs a cleanup story. Prefer idempotent reads, a dedicated read-only token, or an endpoint built for probes. Never aim a DELETE monitor at production data.

Expecting the "wrong" status on purpose

The expected status field is a contract check as much as an uptime check. Calling a protected endpoint without a token and expecting 401 proves the auth layer is alive and not failing open. Expecting 404 on a path that must stay hidden is a cheap regression test for a routing change. For a rate-limited public API, 200,429 keeps a throttled response from paging you while still failing on 500 and 502. You can combine ranges and single codes in one list.

Latency and the slow threshold

Every call stores its response time. On Pro and Agency, set a slow threshold in milliseconds and Tenium compares it with the average of the last three checks, opening a degraded incident rather than a down one when it is exceeded. Averaging three values avoids reacting to one cold start, while still noticing a regression within a few minutes at a one-minute interval. Because the average is across checks that may come from different regions, a threshold should allow for the extra distance to the farthest checker.

Limits worth knowing

Each monitor is one request. There is no chaining (login, then call with the token), no response schema validation, and no assertions on headers. Bodies are read up to about 1 MB without compression, so a very large listing endpoint is a poor choice for a monitor. JSON assertions start on the Starter plan at $7 a month; on Free the same URL can still be watched as a plain website monitor for status and speed. If your API sits behind a WAF, add the checker addresses to the allow list so a challenge page does not appear as a failed assertion.