API monitoring: keep your APIs reliable

APIs carry the traffic that users never see: the mobile app’s login, the shop’s stock levels, the payment confirmation, the call to an AI model behind a support chat. When an API fails or slows down, the damage spreads to everything that depends on it – often in ways that look like unrelated bugs. API monitoring sends regular test requests to your endpoints and checks not only that they answer, but that they answer correctly and fast enough. This guide covers how API monitoring works, how to go beyond “200 OK” with response assertions, how to monitor authenticated and AI APIs, how to set response time thresholds and how to set up a reliable API monitor.

What is API monitoring?

API monitoring is the automated, regular testing of an application programming interface to confirm that it is available, fast and returning correct data. A monitor sends a defined request – method, URL, headers, optionally a body – to an endpoint every minute or every few minutes, measures how long the answer takes and evaluates it against rules you define. When a rule fails, it opens an incident and alerts you.

It differs from website monitoring in what it looks at. A web page is judged by whether it loads; an API response is judged by whether a program can use it. That means checking the status code, the content type, the structure of the JSON and the values of key fields. An API that answers quickly with a well-formed error message is, from the client’s point of view, down.

Why API monitoring prevents cascading failures

APIs often power mission-critical services, and they rarely fail alone. When an authentication API slows down, every service that validates tokens slows down with it; when a pricing API returns empty results, the shop shows products without prices; when a third-party API you depend on goes down, your own features break even though none of your servers did. Timeouts and retries pile up, queues grow and a small problem turns into a system-wide outage.

Monitoring each important endpoint on its own makes the first failure visible. Instead of debugging five symptoms in five services, you see that one upstream endpoint started failing at 14:02 and everything else followed. That shortens incidents dramatically and lets you act – fail over, switch off a feature, inform customers – before the cascade reaches users.

Go beyond “200 OK” with response checks

Status codes alone are not enough. Many APIs return 200 with an error object in the body, an empty array instead of data, a maintenance message or a cached answer from yesterday. Response assertions catch these cases. A typical assertion tests a JSON path: that $.status equals “ok”, that $.items is not empty, that $.items[0].price is greater than zero, that a header has the expected value.

status code        equals     200
$.items            not empty
$.items[0].price   greater than 0
$.currency         equals     "EUR"
response time      below      800 ms

Good monitors let you combine several assertions and decide whether all of them or any of them must pass. Keep them focused on what really matters to consumers of the API – existence of key fields, sensible value ranges, correct types – rather than on volatile details such as timestamps, which would make the monitor fail on every run.

• Status code equals the expected value (often 200 or 201)
• Key fields exist and are not empty
• Values are in a plausible range or equal an expected constant
• Content type is application/json and the body parses
• Response time stays below a threshold

Monitoring AI APIs and model routers

AI endpoints add a new failure mode: they can be available and still return unusable output. A model provider such as OpenAI or Anthropic, or a router such as OpenRouter, may answer with a truncated response, invalid JSON despite a structured-output request, a different model than expected, or a refusal. For applications that parse the output automatically, each of these is an outage.

Monitor AI APIs with a small, cheap, deterministic test prompt and validate the result: that the response parses against your schema, that required fields are present, that the model metadata matches what you configured and that token usage stays within the expected range. Response time thresholds should be more generous than for classic APIs, since generation takes seconds, but a sudden doubling is still a signal worth an alert.

Detect and respond to performance drops

Slow is the new down. An API that takes four seconds instead of 300 milliseconds causes timeouts in clients, abandoned checkouts and retry storms – without a single error in the logs. Set a maximum response time per endpoint and alert when it is exceeded, ideally after two or three consecutive slow checks so that a single outlier does not wake anyone.

When you analyse response times over longer periods, look at percentiles rather than averages. The median shows the typical request; the 95th or 99th percentile shows what your slowest users experience. An average can stay flat while the tail gets much worse, which is exactly the kind of degradation that eventually turns into an outage.

How to set up API monitoring

Setting up an API monitor takes three steps in most tools. First, add the endpoint: choose the request method (GET, POST, PUT, HEAD) and enter the URL, then put it in a group or add tags to keep monitors organised. Second, add request details and assertions: headers, authentication, a request body for POST requests, and the rules the response must satisfy. Third, choose the interval, the timeout and the notification channels, save the monitor and watch the first results come in.

Start with the endpoints whose failure hurts most – login, checkout, search, the health endpoint – and add others over time. Prefer read-only requests; if you must monitor a write endpoint, use a test account or sandbox mode so that the monitor does not create real orders or charges.

• Endpoint: method + URL, grouped by service
• Request: headers, authentication, body
• Assertions: status, JSON fields, response time
• Alerts: interval, timeout, channels, recipients

Monitoring authenticated APIs

Most valuable endpoints require authentication. Common options in monitoring tools are HTTP Basic and Digest authentication and custom headers, which cover API keys and bearer tokens such as JWTs. OAuth 2.0 flows with short-lived tokens are harder, because the monitor must fetch a new token before each check; check whether your tool supports this or expose a dedicated monitoring endpoint.

Authorization: Basic bW9uaXRvcjpzM2NyZXQ=
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…
X-API-Key: mon_live_read_only_4f1c…

Create a separate credential for monitoring with the smallest possible permissions, store it only in the monitoring tool and rotate it like any other secret. If a long-lived token expires, the monitor will start failing with 401 errors – which is useful in itself, because the same thing would happen to your real clients.

API monitoring, website monitoring and synthetic monitoring

API monitoring is one member of a family. Website monitoring checks that pages load; API monitoring checks single endpoints and their data; synthetic monitoring runs scripted, multi-step flows – log in, add to cart, pay – that combine several requests and carry data from one step to the next. Many teams start with single-endpoint checks, because they are quick to set up and cheap to run, and add synthetic flows for the two or three journeys that generate revenue.

Common API monitoring mistakes

The most common mistake is monitoring only a health endpoint that returns “ok” without touching the database or downstream services; it stays green while the real endpoints fail. Others: assertions on volatile values that cause constant false alarms, monitors that create real data, credentials that belong to a person who leaves the company, timeouts so long that slow phases never register, and alerts without enough context to tell which endpoint and which assertion failed. Monitoring third-party APIs you depend on is often forgotten, too, although their outages are frequently the root cause of your own.

Choosing an API monitoring tool

Compare tools on the supported request methods and authentication types, the flexibility of JSON assertions, intervals and check locations, response time thresholds, alert channels such as email, SMS, chat or incident tools, maintenance windows and price per monitor. Affordable uptime services cover single-endpoint checks well; observability platforms and synthetic monitoring tools add scripted flows and deeper tracing at a higher price.

Where monitordefend fits

monitordefend does not send custom API requests and has no JSON assertions. It monitors websites: homepage uptime every five minutes with a confirmation attempt, response time with a threshold alert, broken links, indexing, checkout pages and suspicious changes, all with email alerts. For your APIs, use a dedicated API monitoring tool.

Frequently asked questions

How often should an API endpoint be checked?

Critical production endpoints are usually checked every minute or every few minutes; internal or low-traffic APIs every five to fifteen minutes. Faster intervals detect problems sooner but produce more requests and more data, so match the interval to how quickly a failure starts costing money or users.

Should I monitor third-party APIs I depend on?

Yes, for the ones your product cannot work without, such as payments, login, maps or messaging. Monitoring them separately tells you within minutes whether a failure is on your side or the provider’s, which saves time during an incident and gives you evidence when you contact their support.

What is API monitoring?

API monitoring checks the availability and performance of an API by sending regular requests to an endpoint and verifying the expected response – status code, response time and JSON content. If the API fails or responds too slowly, you get an alert.

Why is a 200 status code not enough?

Many APIs return 200 with an error object, an empty list or stale data. Assertions on the JSON body – fields present, values plausible – catch broken responses that the status code hides.

Can I monitor authenticated APIs?

Yes. Most tools support Basic and Digest authentication and custom headers for API keys and bearer tokens such as JWTs. OAuth 2.0 with short-lived tokens needs explicit support; use a dedicated read-only credential for monitoring.

Can I set custom response time thresholds?

Yes, in most API monitoring tools you set a maximum response time per endpoint and get notified when it is exceeded. Alert after several consecutive slow checks to avoid noise.

How do I monitor AI APIs?

Send a small deterministic test prompt and validate the output: that it parses against your schema, contains required fields, comes from the expected model and stays within the expected token usage and response time.

Does monitordefend offer API monitoring?

No. monitordefend monitors websites – uptime, response time, links, indexing, checkout and integrity – and sends email alerts. It has no custom API requests or JSON assertions.

Related pages

• Website Response Time Monitoring
• Third party monitoring: is it your code, or is it them?
• Keyword monitoring: alert on the presence or absence of a word
• The All-in-One Website Monitoring Tool
• HTTP header checker