API Monitoring
Validate every endpoint, on every deployment.
Modern applications depend on dozens of API endpoints — your own services, serverless functions, third-party integrations and public cloud APIs. NetTests calls them on a schedule, checks the JSON that comes back, and splits every response time into DNS, connect, TLS and server time — so an alert says not just that an endpoint is slow, but where.
Why API failures are hard to detect
Website uptime monitoring checks whether a URL returns a 200 response. But a 200 response from an API endpoint does not necessarily mean the API is working. An endpoint can return 200 with an empty body, an error message, or malformed JSON — all of which would be invisible to a basic HTTP check while completely breaking the applications that consume the API.
API failures also tend to surface in unexpected ways. An authentication endpoint that starts returning 401 for valid credentials will silently log out users. A search API that returns an empty result set instead of a 500 will make it appear as if no records exist. A payment endpoint that times out after 29 seconds — just inside the timeout window — will cause transaction failures without triggering a connectivity alert.
Proper API monitoring goes beyond connectivity checks. It validates that the response contains the expected data structure, that critical fields are present, that latency stays within acceptable bounds, and that authentication is functioning correctly. Only then can you confidently say an API endpoint is healthy.
These failures carry real cost. A payment API returning empty responses processes zero orders while the status page still shows green. A third-party API outage that takes down checkout becomes a revenue incident attributed to your team, not the vendor whose endpoint actually failed. And if the affected endpoint is covered by a customer-facing SLA, a validation gap that goes undetected for hours can trigger service credits that monitoring would have prevented.
How NetTests API monitoring works
Each monitored endpoint is an HTTP request you configure once: method (GET, POST, PUT,
PATCH, DELETE, HEAD, OPTIONS), headers, a JSON, XML, form or GraphQL body, and Basic,
Bearer, Digest or API-key authentication. You can paste a curl command from
your browser's developer tools to fill it in.
JSON field checks assert what the endpoint returned, not just its status
code: a path such as $.status or $.data.items.length() must exist,
equal a value, match a pattern, or be above or below a number. An endpoint that answers
200 with {"status": "degraded"} or an empty list fails the check — and opens an
incident like any other failure.
Latency is measured phase by phase on every request: DNS lookup, TCP connect, TLS handshake and server wait, each recorded and graphed separately. A slow endpoint is then either slow to reach (resolver, network or TLS termination) or slow to answer (the application) — two problems with different owners. Any of them can carry a warn or error threshold.
Checks run on the schedule you set — every minute for a single request — from our monitoring location. Failures and threshold breaches open incidents and notify by email, Slack, Microsoft Teams, PagerDuty, Opsgenie or a signed webhook.
Key features
Any request
Method, headers, JSON / XML / form / GraphQL body and Basic, Bearer, Digest or API-key auth — or import a curl command.
JSON field checks
Assert a JSON path exists, equals a value, matches a pattern, or is above or below a number — tested against a live response in the builder before you save.
Phase-by-phase latency
DNS, TCP connect, TLS handshake and server wait measured on every request, each graphed and alertable on its own.
CDN and edge awareness
For endpoints behind a CDN, every result records which CDN answered, from which edge, and whether it was a cache hit.
Status-code and latency thresholds
Warn and error levels on status, total time, time to first byte or any single phase.
History and baselines
Every run's result and timings are kept, graphed against a trailing 30-day baseline so gradual degradation is visible before it breaches.
Incidents and alerting
Failures open incidents and notify by email, Slack, Teams, PagerDuty, Opsgenie or signed webhook.
Public API access
Read runs, metrics and incidents from the NetTests REST API to feed your own dashboards.
What you'll see
Each check validates more than connectivity — status code, response body, and latency are all graded against your rules. Every row shows exactly what was evaluated on that run, so a failure is never a mystery.
Not ready to commit?
Try the free HTTP Request tool first. Send a real request to your endpoint, see the DNS, TCP, TLS and server time and the full response — no account required — then put the same request on a schedule when you're ready.
Try the free tool →Free HTTP diagnostic tools
Test your API endpoints manually — then automate the checks with monitoring.
Build custom HTTP requests with full control over method, headers, auth, and body — including GraphQL.
See which CDN serves an endpoint, from which edge, whether it was cached — and what it saves over the origin.
Check whether a list of hosts are serving HTTP or HTTPS and responding on standard ports.
Test whether a server supports HTTP/2 and ALPN negotiation.
Connect to a WebSocket endpoint and verify that the handshake completes successfully.
Frequently asked questions
What is the difference between API monitoring and website monitoring?
Website monitoring checks whether a URL returns a successful HTTP response — typically a 200 status code — and optionally validates that expected content is present. API monitoring applies more rigorous validation: it checks response status codes, validates response body structure and content, measures latency against a threshold, and can send authentication credentials or request payloads. API monitoring is designed for machine-readable endpoints rather than human-readable web pages.
Can I monitor APIs that require authentication?
Yes. NetTests supports Basic, Digest, Bearer-token and API-key (header or query parameter) authentication. The credential is stored with the monitor and sent on every check. Endpoints that need a short-lived token fetched first (an OAuth client-credentials flow) can be checked with a multi-step synthetic flow instead.
What do DNS, TCP, TLS and server time tell me?
They split one response time into the parts that have different owners. DNS is your resolver and record setup; TCP connect is the network path to the endpoint; the TLS handshake is certificate and termination work; server wait is your application producing the first byte. If the total doubles and only server wait moved, the problem is in the application — not the network, and not the cloud provider's edge. A request that reuses an open connection has no DNS, TCP or TLS phase, and NetTests records none rather than zeros.
How do I monitor a POST endpoint?
Configure the monitor to use the POST method and provide a request body in the format your endpoint expects — JSON, form-urlencoded, or multipart. Set the appropriate Content-Type header. NetTests will send the exact request you specify on every check cycle and validate the response against your success criteria.
What response latency should I alert on?
Appropriate latency thresholds depend on your application's requirements and user expectations. As a baseline, most user-facing API calls should complete within 200–500ms. Background processing endpoints may tolerate higher latency. Database-heavy queries might have natural variance. The most useful approach is to establish a baseline from historical monitoring data and then alert when latency exceeds 2× the typical value — rather than setting an arbitrary fixed threshold.
How does API monitoring differ from load testing?
API monitoring sends individual requests at low frequency to verify that endpoints are functioning correctly under normal conditions. Load testing sends many concurrent requests to evaluate how an endpoint performs under high load. They serve different purposes: monitoring is a continuous health check in production; load testing is a pre-deployment assessment of capacity. NetTests focuses on production API monitoring — not load generation.
Can I monitor third-party APIs my application depends on?
Yes — monitoring third-party dependencies is one of the most valuable use cases for API monitoring. Many application outages are caused not by a failure in your own code, but by a third-party API going down or degrading. Monitoring those external endpoints gives you immediate visibility into upstream failures, allowing you to notify users proactively and implement fallback behaviors before the failure cascades through your application.
Stop discovering API failures from your own users
NetTests checks your API endpoints on a schedule, asserts the JSON they return, splits their latency into DNS, TCP, TLS and server time, and opens an incident the moment something breaks.
Start monitoring free →