How to monitor a REST API

CHECK YOUR HEALTH ENDPOINT

Start with a dedicated health check

Most APIs have a /health or /api/status endpoint that returns a simple 200 when the service is running. Create an HTTP monitor in Larm pointing at this URL. Set the expected status code to 200.

But don't stop there. A health endpoint that always returns 200 isn't testing much. The best health endpoints check downstream dependencies — database connectivity, cache availability, external service reachability — and return a non-200 when something is actually broken.

VALIDATE THE RESPONSE

Use keyword validation

A status code alone isn't enough. Your CDN might return a 200 with a cached error page. Your API gateway might return a 200 with an empty body. Use Larm's expected keyword validation to check that the response body contains a specific string — like "status":"ok" or your application name.

You can also set an unexpected keyword — a string that should never appear in a healthy response. If your API returns "error" or "maintenance" in the body, that's a failure even if the status code is 200.

CHECK FROM MULTIPLE LOCATIONS

Multi-probe voting eliminates false positives

An API that's reachable from Virginia but not from Singapore might have a CDN issue, a DNS propagation problem, or a regional routing failure. Larm checks from multiple probe locations across multiple continents. A single location failing doesn't trigger an alert — only a majority of probes agreeing that the service is down will page your team. This is the difference between 3 AM noise and 3 AM signal.

MONITOR THE DETAILS

Use the request waterfall

Larm captures the full request waterfall for every HTTP check: DNS resolution, TCP connect, TLS handshake, time to first byte, content transfer. When your API gets slow, you don't just see a number going up — you see that it's the TLS handshake from Frankfurt that's degrading, or that DNS resolution is taking 400ms from Singapore. The waterfall tells you where to look.

Try it with your API endpoint →

AUTHENTICATED ENDPOINTS

Monitor endpoints behind auth

Your public health endpoint is a start, but your authenticated API endpoints are what your users actually hit. Larm supports custom headers — add your API key or Bearer token to the monitor's headers and check the endpoints your customers use. Set the expected status code to whatever your API returns for authenticated requests (200, 201, 204).