To monitor an API for errors and not just uptime, check three things on every
request: the status code, specific fields inside the JSON response body, and the
response time. An endpoint can return 200 OK and still be broken:
an empty array where there should be orders, a null auth token, an error
object wrapped in a success envelope, or a field that quietly changed from a number to a
string. A monitor that only asks “did the endpoint answer?” passes all of
those. You need it to read the payload.
This matters most for the APIs your product actually depends on, the payments endpoint, the auth service, the search backend, a partner's data feed. When one of those degrades without going fully down, the failure is invisible to status-only monitoring and very visible to your users. Here is how to check the things that catch a real API problem.
The three layers of an API check
| Layer | Assert on | Catches |
|---|---|---|
| Status code | Exactly 200 (or 201, 204), not just “under 400” | Hard failures, 5xx, redirects to a login page |
| Response body | A JSON path like $.status == "ok" or $.data[0].id exists | Empty results, error objects with a 200, schema changes, null fields |
| Response time | Under a threshold you set, e.g. 800 ms | Degradation before it becomes a timeout, a slow dependency |
Assert on the status code precisely
Start with the code, but be strict. “Any 2xx or 3xx is fine” is too loose, because a 302 redirect to a login page means your auth expired, and a 204 where you expected a body means something is wrong. Assert on the exact code the endpoint should return. If your API uses 200 for success and 401 for an expired key, a check that tolerates “anything under 400” will happily pass a 401 and never tell you the key died.
Read a field inside the JSON body
This is the layer most monitoring skips, and it is where the real value is. Have the monitor parse the response and assert on a JSON path. A few patterns that pay off:
- A success flag: assert
$.statusequals"ok", so an error object returned with a 200 status still fails the check. - A non-empty collection: assert
$.data[0].idexists, so an endpoint that suddenly returns an empty list, a common silent failure after a bad deploy, gets caught. - A required field with the right type: assert a token or a price field is present and non-null, so a schema change that drops or renames a field surfaces immediately.
That single body assertion is the difference between finding out about a broken payload from your monitor versus from a user whose order never went through.
Watch response time, not just availability
An API rarely fails all at once. It gets slow first, as a database query degrades or a downstream dependency starts timing out. Set a response-time threshold, say 800 milliseconds, and alert when checks cross it consistently. That gives you a head start: you are looking at the problem while it is still latency, before it becomes a wall of timeouts and a real outage. If you are deciding what promise to make about that endpoint in the first place, what counts as a good API uptime SLA sets out the numbers customers actually accept.
alertping
Catch the 200 that hides a broken payload
Assert on status code, a JSON body field and response time on every check. 30-second intervals, 3-region confirmation, SMS included.
Send auth headers and a real request
Most useful endpoints need authentication, so your check has to send the right headers, a bearer token or an API key, and sometimes a specific request body for a POST. Store those on the monitor and hit a real, representative endpoint rather than a bare health-check URL that always returns “ok”. A health check that never touches the database will stay green through a database outage. Check something that exercises the actual path your users rely on. The same reasoning applies to the machine behind the endpoint, which is why a server monitoring tool watching ports and processes pairs well with request-level API checks.
Monitoring an API you do not control
Some of the endpoints your product depends on are not yours: a partner's data feed, a third-party pricing service, a public API you built a feature around. You cannot fix those, but you absolutely want to know the moment they break your integration, because your users will blame you, not the vendor. Point a monitor at the third-party endpoint with the same body and response-time assertions, so a change on their side shows up as your alert. If you are pulling structured data off pages that were never meant to be an API in the first place, a tool that turns any website into clean, structured data gives you a stable endpoint to monitor instead of a brittle scraper that breaks on every layout change.
Put it together
A properly monitored API has, for each critical endpoint: an exact status-code assertion, at least one JSON body assertion on a field that proves the response is real, a response-time threshold, the correct auth headers, and confirmation from more than one region before it pages you. Run that every 30 seconds and route it to SMS. The result is that a broken payload, an expired key or a slow dependency reaches you as an alert with enough detail to act on, long before it reaches your users. The dedicated setup lives on the API monitoring page, and it sits in the same account as your website monitoring, SSL and cron checks.