API monitoring tool: uptime, response time and validation from 300+ locations

REST API monitoring looks superficially like uptime monitoring and is a different job. An API is consumed by code, not by people, and code is unforgiving in ways a browser is not. A human visitor tolerates a page that renders slightly wrong; an integration that receives a field of the wrong type simply breaks. So API monitoring has to check more layers than "did the server answer", and HostTracker checks them in order, failing at the first one that does not hold.

Layers one to three are what an ordinary uptime check gives you. Four and five are what make it API monitoring - and they are the layers where most real API incidents actually live.

Before anything can be validated, the monitor has to make the request your API expects. The full request surface is available on an API monitor:

The most expressive way to validate a response is to write rules for it. Each rule is one line, rules are combined with AND, and a monitor can carry up to twenty of them. This is the verified starting bundle for a JSON API:

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

Four lines, and between them they cover the four layers that matter: the endpoint answered with a 2xx, it answered with JSON rather than an error page, the payload contains a real result rather than an empty one, and it did all that inside the budget. Individually useful rules from the same catalogue include body.json.path("$.status") eq "ok" for an API's own health verdict, body.json.path("$.error") absent for an error member appearing in an otherwise-successful response, body.json.path("$.version") eq "2.4.1" to catch an unintended rollback, redirects.count eq 0 for an endpoint that should answer directly, and cert.days.left gt 14 for the certificate on the same connection.

What a rule can talk about

Rules read subjects out of the response and compare them. The subjects cover the status code; the total response time and its connect, TLS, DNS, header and body components; the raw body along with its size and a hash of it; structured queries into the payload as JSON, XML, HTML or YAML; individual response headers; the final and original URL and their parts; the redirect chain, hop by hop; the certificate's remaining days, issuer and names; the negotiated TLS protocol and cipher; the addresses DNS returned; and Set-Cookie. Comparisons run from the obvious - equal, less than, greater than - through contains, startsWith, endsWith, matches for a regular expression, containsAny and containsAll for a set, in for a list of acceptable values, and exists, isNumber and unique.

There is also a change-detection axis: a rule can compare this run's value against the previous run's, so you can assert that a counter never goes backwards or that a body hash has not changed - the shape of rule that catches a silent rollback or an unauthorised content change rather than an outage.

Alongside the rule language there is a simpler, single-value path that has been part of API monitoring here for a long time and is often all a check needs. You tell the monitor how to parse the body, how to select one value out of it, and what that value must be:

• Parse as JSON, and the selector is a JSONPath expression.
• Parse as XML, and the selector is an XPath expression - which is what makes SOAP and other XML services straightforward to check.
• Treat it as plain text, and the selector is a multiline, case-insensitive regular expression.

The predicate applied to the selected value covers equal and not-equal, less-than and greater-than in both strict and inclusive forms, membership in a list of acceptable values or exclusion from one, inside a numeric range or outside it, and a test for the value being null or absent altogether.

Every failure in this table returns HTTP 200. That is the entire problem with monitoring an API on its status code alone: the transport succeeded, so the transport reports success.

That last row is worth doing deliberately. A second monitor that sends no credentials and asserts on a 401 is the cheapest way to find out that an authorisation layer has been accidentally disabled - a failure no amount of positive testing will ever surface.

API monitors run from HostTracker's public checkpoint fleet - 300+ checkpoints across 158 cities - and you choose which locations a given monitor uses. Geography matters more for an API than for a website: an endpoint fronted by a CDN or a geo-routed load balancer can be healthy in Frankfurt and failing in São Paulo, and a single-location check has no way to see it. The same goes for DNS - a stale or misconfigured record often propagates unevenly, which looks like an intermittent outage from the inside and a regional one from the outside.

Running from many places raises an obvious risk: more checkpoints, more chances for one flaky network path to cry wolf. HostTracker handles that with a confirmation quorum. When a checkpoint reports a failure, the check is repeated across additional independent checkpoints and the state change is only confirmed once they agree - by default a majority verdict across up to seven agents, with a minimum of three. You can make that stricter, requiring a set number of agents to report the failure or full agreement among them, for an endpoint where a false page is worse than a slow one.

After confirmation, alerting follows the delay each contact chose - immediately, or after 3, 5, 15, 30 or 60 minutes, or 3, 6, 12 or 24 hours of continuous failure - across the nine notification channels: email, SMS, voice call, webhook, Slack, web push, and the messenger apps Telegram, Discord and Viber. The webhook channel is how alerts reach an incident manager or a team chat tool.

The check is a configurable HTTP request plus response analysis, so what it fits follows directly from that.

• REST and JSON APIs are the everyday case, and REST API monitoring is what most accounts set up first: a GET or POST, headers for the credential, and JSONPath or assertion rules over the payload.
• GraphQL works as a POST with the query in the body, then JSONPath into data - and it is worth asserting that the errors member is absent, since GraphQL famously answers 200 with errors inside.
• SOAP and XML services are a POST with the envelope as the body and XPath as the selector, which reaches into the response exactly the way the specification intends.
• Webhook receivers and callback endpoints can be checked for reachability and for the response they give to a well-formed request - valuable, because a receiver that has quietly stopped accepting deliveries produces no error anywhere in your own system.
• Health and readiness endpoints are the highest-value target of all if you have them: your application already knows whether its dependencies are healthy, and an assertion on that verdict turns its own knowledge into an alert.

What does not fit is a sequence - obtain a token, use it, then delete the resource. An API monitor makes one request per run. For a genuine multi-step journey, the browser-driven transaction check is the tool; for the timing of a page rather than an endpoint, see browser access and page-load timing.

1. Try the endpoint first with the free instant HTTP check - no login required - so you can see the status, timing and response you are about to write rules against.
2. Add a monitor and choose the API monitoring type. Set the method, and add the headers or body the endpoint needs; issue the monitor its own credential rather than reusing a person's.
3. Write the assertions. Start with the four-line bundle above - status, content type, one meaningful value from the payload, and a response-time budget - which is a genuinely good default for almost any JSON API.
4. Choose an interval between one minute and 24 hours. Three minutes is the default and a reasonable starting point; reserve one minute for the endpoints an outage on which is an incident.
5. Pick the locations. Two or three regions your consumers actually live in beats a single one, and it is what makes a regional failure visible.
6. Add the contacts, and set each one's alert delay. Not everyone needs to hear about minute one.
7. Let it run for a day, then look at the response-time history before you tighten the timing rule. A budget set from real data holds; one set from a guess gets muted.

These are complementary and frequently confused. An observability or APM platform instruments your code and tells you what happened inside a request. External API monitoring stands outside your infrastructure and tells you what a consumer actually receives. Both are worth having; neither substitutes for the other.

The pattern most teams land on is external monitoring for detection and internal telemetry for diagnosis: HostTracker tells you an endpoint broke, from where, and against which rule, and your own tracing tells you why. Alongside it, a database query monitor often explains an API that got slow, and server load monitoring explains the host it runs on.

• One request per run. No token exchange, no chained calls. Point the monitor at an endpoint whose authentication does not expire, and use a transaction check when the thing you need to prove is a sequence.
• Twenty assertion rules per monitor. Ample in practice - the four-line bundle covers most endpoints - but worth knowing before you plan a hundred-rule contract test.
• Assertion mode replaces the older keyword and status settings. The two models cannot be combined on one monitor; pick the rule language or the legacy keyword mode, not both.
• No OpenAPI or JSON-schema validation. You assert on specific values and structures, not on a whole schema document.
• The request body has a length limit, so a very large POST payload is not the shape this check is built for.
• It is monitoring, not testing. The right target is a read-only or idempotent endpoint. A monitor that mutates data every three minutes from several locations will eventually be the reason for an incident rather than the thing that detects one.