How is API monitoring different from a plain uptime check?

A plain uptime check only confirms the endpoint responds, so a 200 with empty or wrong data passes. API monitoring adds assertions on the body, fields, schema, and latency, catching cases where the connection is fine but the payload is broken. It typically runs authenticated, multi-step transactions rather than a single anonymous ping.

What HTTP status codes count as a failure?

Monitors expecting 2xx success treat 4xx client errors and 5xx server errors as failed runs, for example a 401, 404, 500, or 503. Many also flag unexpected 3xx redirects as regressions. RFC 9110 defines all five families: 1xx, 2xx, 3xx, 4xx, and 5xx.

What latency should an API target?

It depends on the use case, but a common interactive-API target keeps p95 latency under roughly 500 ms and p99 in the low hundreds of milliseconds. Percentiles are used instead of averages because the slowest 1 percent of requests, the p99, is what causes client timeouts. Real-time systems often tighten this to under 100 to 200 ms.

How does API monitoring handle authentication?

Checks send the same credentials a real client would, most often an API key in a header or a bearer/OAuth token. This exercises the protected path rather than a public stub, so the monitor verifies that auth, rate limits, and the actual logic all work. Tokens with expiry should be refreshed by the monitor so checks do not fail on a stale credential.

What Is API Monitoring?

Reviewed by Ionut Caval · Updated June 2026

API monitoring is the continuous, automated checking of REST and GraphQL endpoints for availability, correctness, and speed. It goes beyond a simple health check by asserting on the HTTP status code, the response body, and the time each request takes.

A plain uptime check confirms an endpoint answers. API monitoring confirms it answers correctly. A request can return HTTP 200 and still ship the wrong data: an empty array where ten records belong, a stale price, or a field that silently changed type. API monitoring catches that gap by validating the payload, not just the connection. It is a form of synthetic monitoring aimed at machine-to-machine interfaces rather than rendered web pages.

Every check reads the HTTP status family first. RFC 9110 defines five: 1xx informational, 2xx success, 3xx redirection, 4xx client error (such as 401 Unauthorized or 404 Not Found), and 5xx server error (such as 500 or 503). A monitor expecting 2xx flags any 4xx or 5xx as a failed run, and many treat an unplanned 3xx redirect as a regression too.

What an API monitor asserts

A single check usually chains several assertions. All must pass for the run to be marked healthy:

Status code: the response equals an expected value, for example 200 or 201.
JSON path: a field equals or contains an expected value, such as data.status == "ok" or a non-empty items[] array.
Schema validation: the body matches a defined shape, so renamed or missing fields fail fast.
Response time threshold: the request completes under a budget, for example 500 ms, tied to the endpoint's response time target.
Authentication: the call carries a valid API key or bearer/OAuth token so it exercises the real, protected path.

Latency targets and multi-step checks

Speed is measured at percentiles, not averages, because the slow tail is what breaks callers. A common interactive-API target keeps p95 latency under about 500 ms and p99 in the low hundreds of milliseconds, meaning 95 percent of requests finish within the p95 budget and only the slowest 1 percent exceed the p99 line. Tracking p99 surfaces the timeouts and cold starts that a mean would hide; real-time paths often tighten the budget to 100 to 200 ms.

More valuable still are multi-step transactions: authenticate, create a record, read it back, then delete it, asserting at each hop. This proves an entire workflow, not one isolated route. For checking many endpoints or URLs at once, the bulk checker under Pulsetic's free tools validates status and redirects across a list in a single pass.

Frequently asked questions

How is API monitoring different from a plain uptime check?

A plain uptime check only confirms the endpoint responds, so a 200 with empty or wrong data passes. API monitoring adds assertions on the body, fields, schema, and latency, catching cases where the connection is fine but the payload is broken. It typically runs authenticated, multi-step transactions rather than a single anonymous ping.
What HTTP status codes count as a failure?

Monitors expecting 2xx success treat 4xx client errors and 5xx server errors as failed runs, for example a 401, 404, 500, or 503. Many also flag unexpected 3xx redirects as regressions. RFC 9110 defines all five families: 1xx, 2xx, 3xx, 4xx, and 5xx.
What latency should an API target?

It depends on the use case, but a common interactive-API target keeps p95 latency under roughly 500 ms and p99 in the low hundreds of milliseconds. Percentiles are used instead of averages because the slowest 1 percent of requests, the p99, is what causes client timeouts. Real-time systems often tighten this to under 100 to 200 ms.
How does API monitoring handle authentication?

Checks send the same credentials a real client would, most often an API key in a header or a bearer/OAuth token. This exercises the protected path rather than a public stub, so the monitor verifies that auth, rate limits, and the actual logic all work. Tokens with expiry should be refreshed by the monitor so checks do not fail on a stale credential.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed