Monitoring an API endpoint that needs authentication

Most uptime monitors check that a URL returns 200. For an API that is barely a check at all: a health endpoint can return 200 while the database it depends on is unreachable, because whoever wrote it returned 200 unconditionally.

A real API check sends the credential, reads the body, and asserts on what it says.

A health endpoint worth monitoring

GET /v1/health
Authorization: Bearer sk_live_...

{
  "status": "ok",
  "database": "ok",
  "queue": { "depth": 4 }
}

# Assert on data.status == "ok", not on the status code.
# Return 503 when a dependency is down — a health endpoint
# that always returns 200 is a health endpoint that tells you nothing.

Setting it up

Add an HTTP monitor pointing at the health endpoint.
Open API options and paste the Authorization header — it is encrypted before storage and never shown again.
Set the accepted status range to 200–299 so a 503 counts as down.
Add a JSON path assertion — status must equal ok — so a 200 with a degraded body still fails.
Set a response-time limit. An API answering in nine seconds is technically up and practically broken.

Use a token scoped to reading health

The credential is stored encrypted and sent only to the URL you configured, but the smallest useful token is still the right one. A read-only key that can reach one endpoint limits the blast radius of every possible mistake, including ours.

Return a real status code

If your health endpoint returns 200 with {"status":"degraded"}, every monitor that only reads status codes will call it healthy. Returning 503 when a dependency is down makes the endpoint honest to every tool, not just the one configured to read the body.

Check the thing that breaks

An endpoint that returns a static string proves the web server is running. Have it touch the database, the cache and the queue, and report each — then the check is measuring the system rather than the reverse proxy in front of it.