How to Monitor API Endpoints: Status, JSON Checks, Latency and Cron

An API can be "up" in the sense that the server answers and still be useless: it returns 200 with an empty list, an error object wrapped in a success status, a stale cache or a response that takes eleven seconds. Monitoring an API well means asking three questions on a schedule. Does it respond? Does it respond correctly? Does it respond fast enough? This guide shows how to choose endpoints, check status codes and JSON content, handle authentication without leaking secrets, measure latency, and cover the background jobs behind the API.

Choose what to monitor

Do not monitor every endpoint. Pick the few that tell you the most.

1. A health endpoint. A cheap route such as /health or /healthz that returns quickly and confirms the application is alive. This is your primary availability signal.
2. A deep health endpoint. A route that checks dependencies (database, cache, queue, a key upstream service) and reports their status. Make it less frequent, or protect it, because it costs more to run.
3. One or two critical business endpoints. The ones whose failure would hurt customers: login, product search, create-order, a public read endpoint your mobile app depends on. Use safe read operations wherever you can.
4. Authenticated paths the integration relies on, using a limited test credential (see the auth section).

If you are on a plan with a small number of monitors, as with SiteDownCheck's free tier, a health endpoint plus one or two critical read endpoints gives better coverage than many near-duplicate checks.

Shallow versus deep health checks

A shallow check proves the process runs and will keep passing while the database is down. A deep check catches that, but every probe then hits your dependencies, and one flaky optional service can make the whole API look down. Report each dependency's state in the JSON and decide which ones should fail the check.

Check the status code, but not only the status code

Define the expected status, normally 200, and treat anything else as a failure. Some details:

• Redirects. Decide whether following a redirect is acceptable. A health URL that suddenly redirects to a login page returns a final 200 with the wrong content. Monitor the final response, and read what a request returns with the HTTP Status Checker.
• Expected non-200 responses. An endpoint that should return 401 without credentials can be monitored for exactly that, which proves the auth layer is still in place. Only do this if your tool allows custom expected codes.
• Status code semantics. 5xx indicates a server problem and 4xx a client problem. A sudden wave of 4xx on a valid request often means a deployment changed validation or a key expired. See status codes for definitions.
• Do not confuse 429 with down. Rate limit responses to your monitor mean you are probing too often or sharing an IP range with abusive traffic.

Validate the body: keyword and JSON path checks

A 200 with the wrong content is the most common silent failure. Add content assertions.

Keyword checks look for a string in the response body. For an API this can be a fixed token such as "status":"ok". It is simple, but fragile if JSON formatting or field order changes.

JSON checks parse the body and inspect specific fields. SiteDownCheck's monitors support JSON checks, so you can assert on values rather than text patterns. A JSON path is an expression that selects a field. Common forms are:

Check your tool's documentation for the exact syntax it supports, since JSON path implementations differ. Examples of useful assertions:

• $.status equals ok.
• $.data is not empty for a list endpoint you know should return results.
• $.error does not exist.
• A numeric field is within a range, for example an exchange-rate endpoint where a value of zero means a broken upstream.
• A timestamp such as $.updated_at is recent, which detects stale data from a stuck background job.

Validate a sample response locally before you configure the monitor. The JSON Validator checks that the body parses at all; invalid JSON, such as a PHP warning printed before the opening brace, is a classic reason JSON assertions fail suddenly.

Authentication headers: be careful

Many useful endpoints require authentication. Monitoring them means giving the monitor a credential, which becomes a stored secret.

• Create a dedicated, least-privilege credential for monitoring: read-only, scoped to the endpoints you check, and clearly named so nobody deletes it by mistake. Never put an admin key, a database credential or a personal token into a monitor.
• Use headers, not URLs. Credentials in query strings end up in logs, proxies and referrers. Prefer an Authorization or API key header.
• Assume the monitoring configuration is not a vault. Treat anything entered in a monitoring tool as potentially visible to everyone who can see that monitor, and rotate it regularly.
• Plan for expiry. Short-lived tokens (such as OAuth access tokens or JWTs) will expire and make the monitor fail. If you must monitor with one, use a long-lived scoped key instead. You can inspect a token's claims and expiry time with the JWT Decoder, but never paste production tokens into tools you do not trust.
• Keep safe operations safe. Monitor with GET or HEAD wherever possible. A monitor that issues POST requests to create records will pollute your data, and a monitor that triggers emails or charges is dangerous.
• Watch the failure mode. If the credential is revoked, your monitor will start alerting that the API is down, when the real issue is the key. Name the check clearly, for example "Orders API (auth key: monitoring-ro)", so the responder knows where to look.

Test the request with curl first:

curl -sS -o /dev/null \
  -H "Authorization: Bearer $MONITOR_TOKEN" \
  -w "status=%{http_code} total=%{time_total}s\n" \
  https://api.example.com/v1/orders?limit=1

Measure latency, and decide what slow means

Availability is binary, but latency is where trouble begins. A response that takes 8 seconds will make clients time out, retry and amplify load.

• Record response time for each check and look at the trend, not only single values. A creeping median is a warning of database growth, a missing index or a noisy neighbor.
• Set a timeout that reflects what your clients tolerate. If your mobile app times out after 10 seconds, a check that waits 30 seconds hides the problem.
• Break down where time goes. From the command line, curl reports DNS lookup, connect, TLS and first byte timings:

curl -sS -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://api.example.com/health

• Compare locations. A slow response from one region can indicate routing or CDN trouble rather than an app problem. The outage root cause finder helps narrow it down.
• Distinguish percentiles from averages when you analyze your own logs. Averages hide the slowest requests, which are the ones users complain about.
• Cold starts and caches. First requests after a quiet period may be slower. If your API runs on serverless infrastructure, expect periodic spikes and set thresholds accordingly.

Frequency matters: a 5-minute interval is a reasonable default for most APIs, with shorter intervals for revenue-critical ones if your plan allows.

Browser-facing APIs

If browsers call your API from another origin, a CORS misconfiguration breaks the front end while monitors stay green. Test with the CORS Checker, and monitor certificate expiry on the API hostname.

Monitor the background work: cron and heartbeats

APIs are usually backed by scheduled jobs: syncs, imports, report generation, cache warmers, queue workers. An availability check will not notice that the nightly sync stopped three days ago. Use heartbeat monitoring for these.

1. Create a heartbeat monitor with cron monitoring and set its expected interval.
2. At the end of a successful job run, request the heartbeat URL.
3. If the job fails, hangs or never starts, the ping does not arrive and you are alerted.

# crontab: run the sync, and ping only if it succeeded
*/10 * * * * /opt/app/bin/sync.sh && curl -fsS -m 10 https://<your-heartbeat-url> > /dev/null

Allow a grace period larger than the job's normal duration and its natural jitter. Details are in cron job heartbeat monitoring, and if you run WordPress, WP-Cron explained and fixed covers its quirks.

The "freshness" JSON check above is a good partner: the heartbeat proves the job ran, and the timestamp check proves it produced current data.

Alerting and noise

• Confirm failures with a second check before alerting, and send alerts to a channel someone watches. See how to reduce false alerts.
• Use maintenance windows for planned deploys, so expected failures do not page anyone.
• Document each alert. Link to a runbook that says what the check does, what a failure likely means and the first three things to try.
• Publish status for customers or internal teams through a status page, and review incidents with a postmortem.

Next steps

• Create HTTP and JSON checks with the uptime monitor.
• Add heartbeats for scheduled jobs with cron monitoring.
• Validate response bodies with the JSON Validator.
• Test browser access with the CORS Checker.
• Read cron job heartbeat monitoring.

FAQ

What should an API health endpoint return?

A fast 200 with a small JSON body such as {"status":"ok"}, plus optional dependency states. Keep it unauthenticated or protected by a simple monitoring key, and make sure it does not expose internal details to the public.

Is checking for status 200 enough?

No. APIs often return 200 with an error message or empty data when something is broken. Add a JSON field or keyword assertion and a latency threshold.

Is it safe to put an API key into a monitor?

Only a dedicated, read-only, least-privilege key. Never use admin credentials, send secrets in the URL or reuse a key that other systems depend on, and rotate it on a schedule.

How do I monitor a cron job behind my API?

Use a heartbeat: the job requests a unique URL when it finishes successfully, and you are alerted if the request does not arrive on time.

How often should I check an API?

Every five minutes suits most APIs. Check more frequently for revenue-critical endpoints if your plan allows it, and use failure confirmation so a single blip does not wake anyone.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.