A 200 OK is not enough: monitoring what your API actually returns

Here’s a failure mode that basic uptime monitoring will never catch: your payment API returns 200 OK with a body that says {"status": "failed", "error": "out_of_stock"}. The HTTP layer is perfectly healthy. The check is green. And your customers can’t check out.

A status code tells you the server responded. It says nothing about whether the response was correct. For anything that matters — payments, auth, search, inventory — that gap is where real incidents hide.

What “the API is up” really needs to mean

Treating an API as a black box that’s either up or down works fine for a static page. It falls apart the moment the response has meaning. A useful API check should verify a contract: given this request, the response must look like this.

That contract has several parts, and each is worth asserting:

• Status code — is it exactly 200 (or 201, or whatever you expect), not just “not an error”?
• Response time — did it come back under your threshold? A 4-second checkout API is a problem even at 200.
• Headers — is content-type correct? Are caching and security headers present?
• The body itself — this is the one basic monitoring skips entirely.

Assertions turn a check into a contract

An assertion is a rule the response must satisfy. Stack several on a single monitor, and every one must pass for the check to be green. If any fails — even on an HTTP 200 — the endpoint is treated as down and your team is alerted.

assert status        == 200
assert time          < 800ms
assert header         content-type: application/json
assert body.status   == "ok"
assert body.items     is array
assert body.user.id   exists

The most valuable of these is the JSON body assertion. Using dot notation, you can reach deep into the payload and verify the actual business logic — data.user.active == true, order.total > 0, results.length >= 1. That’s the difference between “the server answered” and “the answer was right.”

Test the request, not just the URL

Real endpoints need real requests. Good API monitoring lets you:

• Choose the method — GET, POST, PUT, PATCH, DELETE.
• Send a request body — a JSON payload to exercise creation and update endpoints properly.
• Attach auth — bearer tokens, API keys, or basic auth, kept encrypted and never shown in logs.
• Run from multiple regions, and require agreement before alerting so a single flaky run doesn’t page anyone.

A quick mental model

Ask yourself: if this endpoint silently started returning the wrong data, how long until someone noticed? If the answer is “when revenue dropped” or “when support tickets spiked,” a status-code check isn’t enough. Assert on the body.

Where to start

Pick your three highest-stakes endpoints — usually auth, payments, and whatever powers your core user action — and write assertions for each. Status, timing, and one or two body fields is enough to catch the failures that hurt most.

Want to check what your API actually returns? Explore API monitoring →