API Monitoring: What to Check Beyond a 200 Status Code.

An API that returns 200 OK can still be broken. It might return an empty list, an error message wrapped in valid JSON, stale data from a cache, or take eight seconds to answer. Good API monitoring checks what the response says, not just that a response arrived.

Key takeaways

• Check the status code, the response time and the body - all three.
• Assert on JSON fields that only have the right value when the API really works.
• Monitor authenticated endpoints with a dedicated, low-privilege test account.
• Use multi-step checks for flows where one call depends on another (login, then fetch).
• Keep monitoring requests read-only, or clean up after them.

Level 1: is it answering?

The minimum check sends a request and expects a specific status code:

curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.example.com/v1/health
200 0.142

This catches crashed servers, broken deploys returning 502, and expired certificates. It misses everything that fails "politely".

Level 2: is it fast enough?

Set a response-time threshold that reflects what clients tolerate. If your mobile app times out after 10 seconds, alerting at 3 seconds gives you room to act. Track the trend too: an endpoint that drifts from 150 ms to 900 ms over a week usually has a growing query or a missing index.

Level 3: is the answer right?

Assert on the response body. For JSON APIs, check fields whose values prove the system works end to end:

{
  "status": "ok",
  "database": "connected",
  "queue_depth": 12,
  "version": "2.14.0"
}

Useful assertions:

• status equals ok - the service reports itself healthy.
• database equals connected - the health endpoint actually tested the database.
• queue_depth is below a limit - background work isn't piling up.
• A list endpoint returns at least one item - an empty catalogue is an outage for a shop.

Check the headers too

Content-Type should be application/json; an HTML error page from a proxy often arrives with status 200 and text/html. Cache headers and CORS headers break clients in surprising ways when a deploy changes them.

Authenticated endpoints

Most valuable endpoints need a token. Monitor them with a dedicated test account that:

• has only the permissions the check needs (read-only where possible),
• holds no real customer data,
• is excluded from analytics and billing.

Store its credentials in the monitoring tool's secret fields, never in a URL query string where they end up in logs.

Multi-step checks

Many real flows chain requests: log in, receive a token, call the API with it, and maybe follow a returned ID. A single-request monitor can't test that. A multi-step API monitor runs the steps in order, passes values from one response into the next request, and reports which step failed:

1. POST /auth/login - extract access_token from the response.
2. GET /v1/orders?limit=1 with Authorization: Bearer {token} - expect 200 and a non-empty list.
3. GET /v1/orders/{id} using the ID from step 2 - expect the same ID back.

When step 1 fails you know it's authentication; when only step 3 fails, it's the detail endpoint.

Don't let monitoring cause damage

• Prefer GET requests. If you must test writes, use a sandbox or a test record that each run overwrites.
• Keep the interval sensible - a check every 30 seconds is about 2,900 requests a day, so don't point it at an endpoint that sends SMS or charges a card.
• Add a recognisable User-Agent so your team can filter monitoring traffic out of logs and analytics.

What to alert on

Frequently asked questions

• Should I monitor a /health endpoint or real endpoints?

  +

  Both. A health endpoint tells you the service thinks it is fine; a real endpoint proves users can actually get data. Health endpoints that don't touch the database are easy to fool.

• How often should APIs be checked?

  +

  Every 1-5 minutes for most APIs, every 30-60 seconds for payment or login APIs where minutes of downtime are expensive.

• Can I monitor GraphQL or SOAP APIs?

  +

  Yes. Send the query as a POST body and assert on fields in the response, exactly as with REST.