How to monitor an API for downtime

If you want the concepts first, start with what API monitoring is. This is the practical half: which endpoints earn a monitor, how to authenticate without leaking secrets, what to assert beyond a status code, and how to tune the whole thing so an alert at 3am is never a false one.

What counts as API downtime

For a website, down usually means an error page. An API fails in three distinct ways, and a monitor that only understands one of them will happily sleep through the other two:

• Hard failures. Connection refused, timeouts, 5xx responses. The easy case; any HTTP check catches these.
• Wrong answers. The endpoint returns 200 OK with an empty array, an error object, or a schema your clients can't parse. To every naive check the API is up; to every consumer it is down.
• Slowness. A payments endpoint answering in nine seconds is technically responding and practically broken, because client timeouts upstream of you are already firing.

“Monitoring an API for downtime” therefore means three assertions per check: it answers, it answers correctly, and it answers in time. Everything below builds towards that.

Choose the endpoints to watch

The most common mistake is monitoring either one endpoint or all of them. One endpoint (usually /health) proves the process is alive while the business logic burns; all of them buries the signal in noise and doubles your traffic. A shortlist beats both:

The health endpoint deserves one extra note, because monitoring amplifies whatever it tells you. A good one is fast, needs no auth, and reports on its dependencies honestly:

GET /health  →  200 · application/json
{
  "status": "ok",
  "checks": { "database": "ok", "cache": "ok", "queue": "ok" },
  "version": "1.42.3"
}

If /health returns 200 even when the database is unreachable, your monitoring inherits the lie. Have it check the things the API cannot live without, and assert on the body (the "status":"ok"), not just the code.

Build the check, step by step

1. 1

   Create an HTTP monitor for the health endpoint

   In the new-monitor dialog, choose the HTTP type and point it at https://api.example.com/health. This is your baseline liveness check; the interesting ones come next.

2. 2

   Call it like a real client

   Match the request your consumers actually send: the right method, an Accept: application/json header, and a request body where an endpoint expects one. The closer the check is to real traffic, the fewer failures can hide between them.

3. 3

   Add auth without leaking secrets

   For protected endpoints, use the monitor's authentication options: a bearer token, a custom header (for API keys), or basic auth. Mint a dedicated, read-only credential for monitoring with the narrowest scope you can, so the token in your monitoring tool is never one worth stealing.

4. 4

   Write the assertions

   Set the expected status codes, a body assertion and a response-time ceiling per endpoint; the next section covers each. This is the difference between checking the API and checking that it merely exists.

5. 5

   Pick the interval and timeout

   Check the shortlist every 30 to 60 seconds (paid plans go to 30 seconds) and secondary endpoints every few minutes. Keep the request timeout below the interval, and generous enough that a slow-but-alive response registers as degraded rather than a timeout.

6. 6

   Route the alerts, then rehearse once

   Send hard failures to the channel that wakes someone (Slack, Teams, Telegram, Discord, email, SMS or a webhook) and degraded to a quieter one. Then force a failure safely: temporarily set an expected status the endpoint never returns, watch the alert arrive, and put it back. Never trust an alert path you haven't seen fire.

Assert more than a status code

A single API check can verify the whole shape of a response. Here is one with all three assertion layers on:

• Expected status codes. List exactly what healthy looks like (200, or 200, 204). Don't accept “any 2xx” when the endpoint has precisely one correct answer, and remember a redirect can mask a broken route.
• Body assertions. Require text to be present ("status":"ok") or absent ("error"). For JSON APIs you can match a specific field with a JSONPath expression, or use a regex where the shape varies. This is what catches the 200-that-lies, the trap the API explainer covers in detail.
• A response-time ceiling. Set a maximum in milliseconds based on what your clients tolerate. Cross it and the monitor turns degraded with the measured time in the message, so a developing slowdown is visible days before it becomes an outage.

Tune out the false alarms

An API monitor you mute is worse than none, and muting always starts with false alarms. Three settings keep the signal clean:

• Confirm from a second region. The internet between one probe and your API fails far more often than your API. A blip seen from one location is re-checked from another before it counts; paid plans check from multiple regions worldwide, so a single flaky path never pages you.
• Require consecutive failures. By default an incident opens after consecutive failed checks, not one. At a 30-second interval that still means alerting within about a minute of a real outage, with almost no one-off noise.
• Separate slow from down. Degraded latency goes to a channel the team reads in the morning; hard failures go to the one that buzzes. If every alert sounds the same, every alert gets the same shrug.

Cover the sequence, not just the endpoints

Clients don't call endpoints in isolation; they log in, create things and read them back. The shortlist already covers the most important sequence (a token is minted, then honoured) as two independent checks. When a flow has to carry state through several calls, chain them into one journey:

Where a real browser is involved (a login form, a redirect dance), drive it with a browser journey instead; for pure JSON flows, chained HTTP checks stay lighter and faster. And two adjacent failures deserve their own monitors while you're here: the certificate on api.example.com expiring quietly (SSL expiry monitoring) and the scheduled jobs that consume your API or deliver your webhooks (heartbeat checks).

Frequently asked questions

Four endpoints, three assertions each, confirmed from more than one region: that's API downtime monitoring that catches hard failures, wrong answers and slowdowns alike. 247Monitor's HTTP and API checks support all of the above on every plan, with 25 monitors free and no card required.