What Is API Monitoring? Types, Metrics and Best Practices

What API monitoring checks

An API is read by code, and code is strict. A browser still shows a page with one broken image, but a client that expects a JSON number and gets an HTML error page fails outright. So an API monitor looks at more than whether the server replied:

• Availability: the hostname resolves, the TCP connection opens, the TLS handshake completes and a response arrives before the timeout.
• Status code: normally 2xx. A 5xx points at the server or something behind it, a 401 or 403 often at an expired or revoked credential, a 429 at a rate limit.
• Latency: how long the call took, ideally split by stage (DNS lookup, connect, TLS, first byte, download) so a slow result points at its cause.
• Correctness: the body has the expected content type, parses, and holds the values of a healthy response. Many real failures return 200 with the wrong body: an empty list, a renamed field, an error object inside a success envelope.
• Error rate: the share of calls that fail over a period. One failed check can be a network blip; a failure rate climbing across several locations is an incident.
• Authentication and TLS: the monitor's credential still works, and the certificate is valid and not close to expiry.

Why p95 and p99 beat averages

Averages hide the slow requests people complain about. The monitoring chapter of Google's SRE book describes a service averaging 100 ms at 1,000 requests per second in which 1% of requests might easily take 5 seconds, and the average shows none of it.

Percentiles show that tail: p95 is the time 95% of requests finish within, p99 the time 99% finish within. Keep failed requests apart from successful ones too, because a 500 that returns instantly pulls the average down and makes a failing service look faster. A scheduled check produces few samples (60 per hour per location at a one-minute interval), so read synthetic percentiles over a day or a week and take short-window p99 from server-side metrics.

Types of API monitoring

The first split is where the data comes from. Synthetic monitoring, also called active monitoring, sends scripted requests on a schedule from machines you choose, whether or not anyone is using the API. Real-traffic monitoring, also called passive monitoring, reads what actual clients did from access logs, API gateway metrics or an APM agent. The synthetic vs real user monitoring guide compares the two in more depth. The second split is how deep a check goes:

Type	What it does	What it catches	What it misses
Uptime check	Calls one endpoint and checks reachability, status code and response time	Outages, 5xx errors, timeouts, expired certificates	A 200 response with a wrong or empty body
Functional check	Calls one endpoint and applies assertions to headers and values in the body	Schema changes, empty results, error objects inside a 200, the wrong content type	Failures that need an earlier step, such as a token exchange
Multi-step check	Chains calls and passes data between them: get a token, create a resource, read it back, delete it	Broken workflows, token issuing, writes that do not persist	Endpoints outside the scripted flow; it also needs test data and cleanup
Performance check	Records the timing of each stage and alerts on a threshold or a regression	Gradual slowdowns, one slow region, slow DNS or TLS	Wrong data, unless combined with assertions
Real-traffic monitoring	Aggregates status, latency and errors from real requests in logs, gateways or APM	Problems that hit specific clients, endpoints or API versions under real load	Endpoints nobody called recently, and outages where requests never reach you

Uptime, functional and performance checks are often settings of one synthetic monitor: an uptime check with a few assertions and a response-time limit covers all three.

API monitoring vs API testing vs APM

The three share tools and vocabulary but answer different questions:

	API testing	API monitoring	APM and observability
Question it answers	Does this build behave as specified?	Is the live API working for its consumers right now?	Why is a request slow or failing inside the system?
When it runs	Before release, in CI or on demand	Continuously, in production	Continuously, on real traffic
Where it runs	A test or staging environment	Outside your infrastructure, from several locations	Inside your services, through an agent or SDK
Coverage	Many cases, including edge cases and error paths	A few representative calls per endpoint	Every request that reaches an instrumented service
Typical output	Pass or fail for a build	An alert and an availability record	Traces, metrics and logs for diagnosis

Testing stops a broken change from shipping. Contract tests often compare every response with the API's OpenAPI description, which is too heavy and too risky to repeat against production every minute. Monitoring catches what no test run can: an expired certificate, a dependency outage, a configuration change made outside a deploy, a region that lost its route. APM then explains a slowdown that monitoring detected. The SRE book calls this outside view black-box monitoring: symptom-oriented, reporting that the system is not working correctly right now. If a live API gets only one of the three, make it external monitoring, since it keeps reporting when the whole platform is down.

How a synthetic API check works

Take a monitor for an endpoint that lists orders. Each run sends the request a client would send, with the monitor's own read-only token:

curl -sS -i "https://api.example.com/v1/orders"   -H "Accept: application/json"   -H "Authorization: Bearer $MONITOR_TOKEN"

A healthy response looks like this:

HTTP/2 200
content-type: application/json; charset=utf-8

{"count": 2, "orders": [{"id": 1041, "status": "open"}, {"id": 1042, "status": "shipped"}]}

Each run goes through the same steps:

1. The scheduler starts the check at every location you selected.
2. The agent resolves api.example.com, opens a TCP connection and completes the TLS handshake, validating the certificate chain, hostname and expiry date.
3. It sends the request with your method, headers and body, and starts the timeout clock.
4. It records the status, headers, body and the duration of each stage.
5. It evaluates the assertions. The run passes only if all of them hold.
6. If the run fails, the monitor usually confirms it from other locations before changing the state and alerting anyone, and does the same before announcing a recovery.

For this endpoint, four assertions are enough:

• The status is in the 2xx range.
• The Content-Type header contains json, which catches an HTML error page that a proxy serves with a 200.
• The JSON field $.count is greater than 0. Pick a value that is never legitimately empty: if this account always has orders, a zero means the data layer broke.
• The total response time is under 5 seconds.

In HostTracker's assertion rule language the same four expectations read:

status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5s

API health check endpoints

Many APIs expose a route such as /health or /healthz where the service reports on its own health. A useful health endpoint:

• Returns 200 when healthy and an error code such as 503 when not, so a plain status check reads the verdict without parsing the body
• Answers fast and cheaply, because load balancers, orchestrators and monitors may call it every few seconds
• Lists each critical dependency (database, cache, queue, upstream APIs) separately, so an alert can name the one that failed
• Is never cached by a CDN or proxy

It should not expose secrets, internal hostnames or stack traces; if operators need a detailed view, put it behind authentication. An IETF Internet-Draft proposes a format for these responses: a JSON body served as application/health+json, with a status of pass, fail or warn tied to the HTTP code (2xx or 3xx for pass and warn, 4xx or 5xx for fail). The draft expired without becoming a standard, but its field names make a sensible template.

Liveness vs readiness

Kubernetes splits the health question in two, and the split helps outside Kubernetes too. A liveness probe asks whether the process is alive and making progress; when it fails more often than the configured tolerance, the kubelet restarts the container. A readiness probe asks whether the instance can take traffic right now; when it fails, the pod's address is removed from the Services that route to it until the probe passes again.

Keep dependencies out of liveness. If the liveness check queries the database, a database outage restarts every instance at once, and the Kubernetes documentation warns that a badly implemented liveness probe can cause cascading failures. For an app with strict back-end dependencies, it describes a liveness probe that passes when the app itself is healthy and a readiness probe that also checks each required back-end service.

Why a 200 from /health is not proof

A health endpoint reports what the service believes about itself, through a code path real requests do not take: it usually skips authentication, runs no business logic and serializes no real data. The service can answer {"status": "pass"} while the orders endpoint fails after a bad deploy, and a reverse proxy configured to answer /health itself proves only that the proxy is up. Use the health endpoint for its dependency verdict, and monitor at least one real, read-only business endpoint with data assertions next to it.

API monitoring best practices

• Alert on symptoms. Page someone for what clients experience, such as failed calls or wrong data, and keep causes like high CPU on dashboards until they reach a response. The SRE book asks of every alerting rule whether it detects something urgent, actionable and visible to users.
• Confirm a failure from several locations before alerting. One checkpoint can fail because of its own network path, so require two or more locations to agree, and run from the regions your clients are in. The recheck strategies guide compares the options.
• Monitor the dependencies you call. Your API is only as available as the payment provider or identity service behind it. A light check on each critical upstream endpoint shows whether a rise in your own errors started there; keep its interval modest so it does not use up your quota or earn a 429 Too Many Requests.
• Test the auth path both ways. Check that the monitor's own credential still works, so a rotated or expired key becomes an alert instead of a customer ticket. Add a second check that sends no credential and expects 401. RFC 9110 requires a 401 response to carry a WWW-Authenticate header, so you can assert on that too.
• Keep timeouts realistic. Measure for a few days, then set the response-time alert above the p95, with separate thresholds for slow and down. Mind your clients' own timeouts: if the mobile app gives up after 10 seconds, a 15-second response is an outage for its users, whatever the monitor records.
• Make checks version-aware. While clients still call /v1, monitor it as well as /v2. Send the version header your clients send, and if the API reports its version in a field, assert on it to catch an unintended rollback.
• Prefer read-only calls. RFC 9110 defines GET, HEAD, OPTIONS and TRACE as safe methods. A monitor that creates an order every minute from five locations creates 7,200 orders a day, so keep write checks on a test account and clean up after them.
• Keep secrets out of monitors. Give each monitor a dedicated read-only token, never a person's login or an admin key, and send it in a header rather than the query string, because URLs end up in logs and reports. Rotate it like any other secret.

How to choose an API monitoring tool

Run each candidate against the same few endpoints for a week and compare:

• Locations: how many, where, whether you pick them per monitor, and whether failures are confirmed from several
• Request control: every HTTP method, custom headers, a request body, your API's authentication scheme, redirects and timeouts
• Assertion depth: status, headers, JSON and XML paths, timing per stage and comparison with the previous result, in rules that are validated when you save them
• Multi-step support, if your critical flow needs a token exchange or chained calls
• The shortest check interval, and whether your plan gets it for the endpoints that matter
• Alerting: the channels your team reads (email, SMS, chat, webhooks into an incident tool), delays per contact and recovery notices
• Status pages that the API's consumers can follow
• How long results are kept, and uptime reports you can show against an SLA
• An API or a Terraform provider, so a new endpoint gets its monitor in the same change that ships it

How HostTracker monitors APIs

HostTracker's API monitoring sends the request you configure, with method, headers, body and authentication, to REST, GraphQL and SOAP endpoints from 300+ checkpoints in 158 cities, and checks the status, headers, response time and payload against rules you write. It rechecks a failure from other locations before it sends an alert by email, SMS, voice call, Slack, Telegram or another channel. Each monitor makes one request per run, so a chained flow belongs in a transaction check. The API check setup guide covers every setting, and the free HTTP check shows what an endpoint returns from outside before you write rules for it.

Frequently asked questions

What is REST API monitoring?

It is API monitoring applied to REST endpoints: resource URLs called with standard HTTP methods, usually returning JSON. REST APIs signal most errors through status codes, so status assertions do much of the work, but you still need body assertions to catch a 200 that carries the wrong data.

How often should an API be checked?

Every minute for endpoints whose failure is an incident, every five minutes or so for the rest. The time to detect an outage is roughly the interval plus the time spent confirming it from other locations, so the interval sets how fast you hear about it.

Can you monitor an API that needs authentication?

Yes. Send the credential the way a client does, usually an Authorization header with a bearer token or an API key header, and give the monitor its own key. Short-lived tokens are the hard case: a single-request check cannot refresh one, so use a long-lived key on a read-only route, or a multi-step check that fetches a token first.

How do you monitor a GraphQL API?

Send a POST to the GraphQL endpoint with the query in a JSON body. Many GraphQL servers answer 200 even when the query failed and put the details in an errors array, so assert that errors is absent and that a field under data holds the value you expect. A status check alone can report a failing GraphQL API as healthy.

Sources and further reading

• RFC 9110, HTTP Semantics: status code classes, safe and idempotent methods (section 9.2), and the 401 response (section 15.5.2).
• Google SRE book, Monitoring Distributed Systems: the four golden signals, tail latency, symptoms versus causes, and black-box monitoring.
• Kubernetes: Liveness, Readiness, and Startup Probes: what each probe does and why liveness probes need care.
• Health Check Response Format for HTTP APIs: the expired IETF Internet-Draft behind application/health+json.