How to monitor

How to monitor an API

A 200 response doesn't mean your API works. Here's how to monitor an API properly — status, latency, payload correctness, auth and SSL — so you catch real failures before your customers do.

StatusCat3 min read

Monitoring an API is not the same as monitoring a website. An API can return a perfect 200 OK while handing back malformed data, an empty result, or a stale cache. Real API monitoring checks that the response is correct, not just present.

Here's how to do it properly.

What to actually check

  1. Status code. The baseline: is it 200 (or your expected code)? Alert on 4xx/5xx.
  2. Response body. Assert on content. A keyword or JSON check confirms the payload contains what it should — a field, a value, a "status":"ok". This is what catches "up but broken."
  3. Latency. Track response time on every check and alert when it crosses a threshold. A slow API is a failing API to your users.
  4. Authentication. If the endpoint is protected, verify the auth path works — using a dedicated monitoring token, never a real user's credentials.
  5. TLS certificate. APIs go down hard when a certificate expires. Monitor expiry separately (see our SSL expiry guide).

Build a proper health endpoint

The best thing you can do is expose a dedicated /health (or /healthz) endpoint that:

  • Checks the critical path — database connection, cache, and any hard dependency.
  • Returns a small, predictable body, e.g. {"status":"ok"}.
  • Is cheap — no heavy queries, so the monitor doesn't add load.
  • Optionally returns 503 when a dependency is unhealthy, so your monitor trips immediately.

Then point a keyword check at it asserting on "status":"ok".

Set it up in StatusCat

  1. Create an HTTP monitor pointing at your endpoint (e.g. https://api.example.com/health).
  2. Add a keyword assertion so a 200 with the wrong body still counts as a failure.
  3. Set the interval — 1 minute for production, 30 seconds for critical endpoints.
  4. For authenticated checks, add the required header/token (a scoped monitoring token).
  5. Wire alerts and escalation to Slack, PagerDuty, SMS or a webhook, so the right person hears about it fast.
  6. Add an SSL check on the same host to catch certificate expiry.

Don't forget the basics

  • Re-check failures before paging (StatusCat does this automatically) so a single blip doesn't wake anyone.
  • Monitor each critical endpoint, not just the root — auth, checkout, and webhook receivers each fail differently.
  • Put your API on a status page so customers can self-serve during an incident.

New to this? Start with what uptime monitoring is. StatusCat covers all of the above — multi-protocol checks, keyword assertions, 12 alert channels and on-call — free for 50 monitors.

Frequently asked questions

How often should I check my API?
Every minute is a good default for production APIs; drop to 30 seconds for critical, revenue-facing endpoints. Free-tier checks every 5 minutes are fine for internal or low-stakes APIs.
Should I monitor authenticated endpoints?
Yes — but use a dedicated, least-privilege monitoring token, not a real user's credentials. Point the check at a lightweight authenticated health endpoint that exercises your auth path without side effects.
What's a good API health-check endpoint?
A cheap endpoint that verifies the critical path — database reachable, key dependencies healthy — and returns a small, predictable JSON body like {"status":"ok"}. Avoid heavy queries so the check itself doesn't add load.

Keep reading