The core API monitoring best practice is to monitor the endpoints that cost money when they fail, assert on the response body rather than the status code alone, check them every 30 to 60 seconds from more than one region, and route only confirmed failures to a human. Almost every bad monitoring setup breaks one of those four rules, usually the second one, and the result is a dashboard full of green checks over an API that has been returning empty results since Tuesday.
Most teams set up API monitoring once, point it at /health, and never look at it
again. That check proves the process is running and the load balancer is routing. It proves
nothing about whether the API does its job. Below is what to do instead, in the order that gets
the most protection for the least ongoing effort.
Monitor the endpoints that cost money, not the ones that are easy
Start by listing the endpoints where a failure has a direct cost: payments, authentication, checkout, search, the partner feed your customers pull from, the webhook receiver that ingests orders. Those get frequent checks and real escalation. Everything else can be checked less often and routed to a channel nobody gets paged for.
This ordering matters more than tool choice. A team monitoring six revenue endpoints properly is in far better shape than one monitoring two hundred endpoints at five-minute intervals with alerts going to a shared inbox. Coverage without prioritization creates volume, and volume is what eventually gets a monitoring channel muted.
A useful test for each candidate endpoint: if this returned garbage for an hour, who would notice and how? If the answer is "a customer would email support", monitor it. If the answer is "nobody, ever", ask why it exists.
Assert on the response body, not just the status code
This is the practice that separates API monitoring from pointing an uptime checker at a URL. An
endpoint can return 200 OK and be completely broken, and that failure mode is more
common than a hard 500 because modern stacks are good at catching exceptions and bad at noticing
when a query returns nothing.
| Assert on | Example | Catches |
|---|---|---|
| Exact status code | Exactly 200, not "under 400" | Redirects to a login page, 429 throttling, 304 caching surprises |
| A field that only exists on success | $.data[0].id is present | Empty result sets, broken joins, a filter that matches nothing |
| A value, not just presence | $.status == "ok" | Error objects wrapped in a success envelope by a gateway |
| Response time | Under 800 ms | Degradation weeks before it becomes a timeout |
| Payload size sanity | Body longer than a floor you set | Truncated responses, a serializer returning an empty object |
One good assertion beats five weak ones. Pick a field that is genuinely load-bearing, meaning it
can only be populated if the database was reached, the query ran and the serializer worked. An
id on the first element of a list does that job better than a version
string that is hardcoded in the response.
Resist the urge to assert on everything. Every assertion is a thing that breaks when the API legitimately changes, and a monitor that cries wolf after every release gets disabled by the engineer who is tired of it. The technique for each layer is covered in more depth in our guide to monitoring an API for errors.
Pick the interval from the cost of the downtime, not from the price list
You find out about an outage roughly half a check interval after it starts. A five-minute interval hides about two and a half minutes of downtime on average and up to five in the worst case. A 30-second interval cuts that to about 15 seconds. That is the entire mechanic, and it is why the interval question is really a question about what a minute of failure costs you.
| Endpoint type | Interval | Average detection delay |
|---|---|---|
| Payments, auth, checkout | 30 seconds | About 15 seconds |
| Public API customers depend on | 60 seconds | About 30 seconds |
| Partner feeds and webhooks | 1 to 5 minutes | 30 seconds to 2.5 minutes |
| Internal tools, admin endpoints | 5 minutes | About 2.5 minutes |
Set this per monitor rather than picking one interval for everything. The common mistake is choosing a plan tier based on the fastest interval you want on your most critical endpoint, then applying it to all two hundred monitors and being surprised by either the bill or the noise. On run-priced tools that decision is expensive: fifty endpoints at one-minute intervals from three locations is over six million check runs a month. The reasoning behind interval choice is worked through in how often you should check uptime.
Check from outside your own infrastructure, and from more than one place
A monitor running inside the cluster it watches is testing the application, not the path your users take. It will not see a DNS failure, an expired certificate at the edge, a misconfigured load balancer, a CDN rule that started returning stale content, or a regional network problem. It also goes down at exactly the moment you need it.
Multiple locations matter for a second reason: they are how you tell an outage from a blip. A single failed request from one region is usually transient packet loss. Three regions failing at once is an outage. Monitoring that re-checks from a second and third location before alerting removes most false pages without slowing real detection meaningfully, which is the tradeoff that makes fast intervals usable at all.
Handle authentication deliberately
Most endpoints worth monitoring sit behind a token, and this is where monitoring setups quietly rot. A monitor authenticating with a personal access token belonging to an engineer who left will start failing months later and nobody will know why. Three rules keep this clean:
- Use a dedicated service account for monitoring, never a person's credentials, and label it so the next engineer knows what it is for.
- Give it the narrowest scope that lets the check pass. A monitor calling a read endpoint does not need write permissions.
- Know how the token expires. If it is short-lived, the tool needs to refresh it. If it is long-lived, put its expiry in the same calendar as your certificates.
Also decide what a 401 means to you. Most teams want it treated as a failure, because a monitor that silently accepts an auth error is only checking that the server is reachable. If your API is one of the ones being called by autonomous software rather than by your own front end, uptime is also only part of the exposure, and it is worth pairing the check with controls over what those callers are allowed to do before an endpoint is opened up more widely.
Alert like someone has to answer it at 3am
Every alerting decision should be judged against one question: if this fires at 3am, is the person it wakes glad it did? That standard eliminates most bad practice on its own.
Route confirmed failures to a channel that interrupts, meaning SMS or a phone call for the revenue endpoints and Slack for the rest. Email alone is where alerts go to be missed. Check whether your tool includes SMS or sells it as credits, because that detail changes the real cost of a plan more than the headline price does. Then set escalation so an unacknowledged page moves to a second person rather than sitting unread.
Just as important: make it easy to not alert. Schedule maintenance windows so a planned deploy does not page anyone, and set a failure threshold so one blip does not. Alert fatigue is not a personality problem, it is a design failure, and it ends with a muted channel and an outage nobody saw.
Monitor the things around the API too
An API rarely fails in isolation. Three adjacent checks catch a large share of real incidents and cost almost nothing to add:
- The TLS certificate on the API hostname. Certificates on
api.subdomains expire quietly because no human loads them in a browser, and machine clients fail hard with no way to click through a warning. Public certificate lifetimes dropped to 200 days in March 2026 and fall further, so this happens more often than it used to. - The scheduled jobs behind the API. If a nightly import stops, the endpoint stays up and serves stale data forever. A heartbeat check that expects a ping and alerts when it does not arrive catches the silent version of that failure.
- Dependencies you do not own. Monitor the third-party APIs you call. When a payment provider degrades, knowing before your customers tell you changes the conversation entirely.
Review the monitors on a schedule
Monitoring configuration decays because APIs change and nobody updates the checks. Once a quarter, spend thirty minutes on three questions: which endpoints shipped since last time and have no monitor, which monitors have alerted and been dismissed as noise, and which assertions are now checking a field that no longer matters.
A monitor that has fired ten times without anyone acting is not a monitor, it is a notification. Either tighten it so it only fires on something real, or delete it. The value of the whole system rests on people believing an alert means something, and that belief is spent every time a false one fires.
The short version
Monitor the endpoints with a cost attached. Assert on a field that can only exist if the request genuinely worked. Check every 30 to 60 seconds where it matters and less often where it does not. Run the checks from outside your infrastructure and confirm from a second region before paging. Use a scoped service account with a known expiry. Send confirmed failures somewhere that interrupts, and delete the alerts nobody acts on. If you are still choosing a product, the API monitoring tools comparison covers how the main options differ on assertions, interval and price.