API Monitoring: Assertions Beyond a 200 OK

API monitoring is the practice of calling your own endpoints on a schedule and checking the whole response, not just the status line. The useful version asserts on the body, the latency and the content type. A check that only asks for a 200 is a check that will stay green through most of the failures your users report.

What does API monitoring actually check?

A well-built check answers four questions at once. Did the endpoint respond? Did it respond quickly? Did it return the shape the client expects, and the values the client needs? Miss any one of those and you have a monitor that reassures you while the integration is broken. The Problem Details spec exists precisely because APIs fail in ways a status code cannot express.

Start with the contract your consumers depend on. If a mobile client breaks when items comes back empty, then items is part of the contract and belongs in an assertion. If a partner parses currency, assert on currency. Everything else is noise you will eventually mute.

Why a 200 OK is not a passing test

Plenty of broken responses carry a 200. A cached page served while the database is unreachable returns 200. A GraphQL endpoint returning {"errors": [...]} returns 200 by design. A framework that swallows an exception and renders an empty list returns 200 with a perfectly valid envelope.

MDN's definition of 200 is only a statement that the request succeeded, which is a much weaker claim than "the answer is correct". We tested this on a staging checkout endpoint by pointing it at an empty database. The status stayed 200, the response time improved, and every status-code-only check reported the service as healthy.

Which endpoints deserve a monitor?

Not every route needs a check, and watching all of them is the fastest way to build an alert stream nobody reads. Rank endpoints by what breaks when they fail. A payment callback that silently drops orders outranks a search suggestion route that degrades gracefully.

Three tiers work well in practice. Tier one is anything a paying customer or a partner integration calls directly. Those get checked from several regions at the shortest interval you can afford. Tier two covers the internal routes your own front end depends on, checked from one or two regions at a minute. Tier three is everything else, which earns a dashboard rather than a pager.

That ranking is also what keeps an API monitoring budget honest. Ten checks go a surprisingly long way when the first tier is genuinely small. Teams that skip the ranking step tend to end up with forty monitors, of which four matter, and a rotation that has learned to ignore the other thirty-six.

The four assertions worth writing

Keep the set small enough that a failure is unambiguous. Four conditions cover most public endpoints without turning the monitor into a test suite. Each one maps to a documented field on the monitor, so the whole check stays readable as configuration.

Condition	What it catches	Monitor field
Status code is 200	Hard failures, 5xx, gateway errors	expectedStatus
Response time under a ceiling	Degradation before it becomes an outage	responseTimeThresholdMs
Body contains a known string	Empty or wrong payloads behind a valid envelope	keyword
Two cycles before alerting	A single dropped packet paging someone	alertAfterCycles

We prefer a ceiling set roughly at twice the observed p95 rather than at a round number. A threshold pinned to real history alerts on genuine drift instead of on your intuition about what feels slow.

Building the monitor

Use the keyword type when the body matters, because it grades the response text as well as the status. The call below creates that check on a public health route.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "partner orders v2",
    "type": "keyword",
    "target": "https://example.com/api/v2/orders/health",
    "method": "GET",
    "intervalSec": 60,
    "regions": ["los-angeles", "london", "singapore"],
    "keyword": "\"status\":\"ok\"",
    "expectedStatus": [200],
    "responseTimeThresholdMs": 800,
    "alertAfterCycles": 2
  }'

The endpoint and the field names are documented on the monitoring API reference. Every field in that payload is readable later, so treat the monitor definition as configuration and keep it in the repo next to the service it watches.

Authenticated endpoints and expiring tokens

Most interesting routes need credentials, and credentials expire. A long-lived token in a monitor is a silent time bomb: the check goes red at 3 a.m. months later, and the first assumption is always an outage rather than an expiry.

Two habits help. Give the monitor a read-only service account scoped to a single health route, so a leaked token buys an attacker nothing. Rotate that credential on the same schedule as every other secret, and record the expiry date somewhere a human will read it.

Then add a second monitor against the token issuance endpoint itself, asserting that a fresh token comes back with a sane expiry. When monitoring API routes that sit behind OAuth, that second check is what tells you the problem is auth rather than the service.

How often, and from where?

Interval and vantage points matter more than assertion count. A single check from a single location cannot tell a dead service from a bad network path. It either pages you for nothing, or it waits too long to be useful.

Six probe regions are available as of September 2026, with the egress ranges listed on the probe IPs page for allowlisting. Run every check from at least two, and require both to agree before an alert fires. That confirmation step is the whole argument in cross-region quorum confirmation, and it is the difference between a pager you trust and one you mute.

Interval depends on the plan and on how fast you need to know. The free tier runs at 1-minute intervals and the paid tiers go to 30 seconds as of September 2026, which is documented on the pricing page.

Where API monitoring stops

An external probe reads what the endpoint returns and nothing else. It cannot tell you which query was slow, which dependency timed out, or how deep the work queue was when the request arrived. Those numbers come from instrumentation running inside the process, and that is a different category of tool.

It also cannot safely exercise write paths. Creating real orders every 30 seconds to prove the write path works will pollute your data and eventually your billing. Use a dedicated sandbox tenant for that, or accept that the read path is what you are watching. The same boundary applies to the outside-in view described in blackbox monitoring, and the signals split cleanly along the lines set out in the four golden signals.

Common mistakes

Monitoring the documentation route instead of the service. A /health handler that returns a hardcoded string proves the web server is alive and nothing more. Make the health route touch at least one real dependency.

Asserting on the entire response body. Exact-match assertions on a full JSON document fail on every harmless field addition. Assert on the two or three fields that matter and ignore the rest.

One monitor for a whole API. A single check on /v1/ tells you that something is wrong somewhere. Give each critical route its own monitor so the alert names the broken thing.

Treating API monitoring as a replacement for tests. A probe running in production is a smoke detector, not a suite. It should confirm that a deployed endpoint still behaves, while the detailed correctness work stays in CI where a failure costs nothing.

Good API monitoring is mostly assertion design. Pick the handful of endpoints your customers actually depend on. Assert on the fields their clients parse, and set the latency ceiling from your own p95. Run each check from two regions with confirmation. Ten monitors are included on the free plan as of September 2026, which is enough to cover a small public surface. You can start free and have the first check running in a few minutes.