API monitoring that checks the answer, not just the status
UptimePilot calls your API endpoints on a schedule from US East and EU Central, with the method, headers, body and credentials you define. It checks the status code, the response time and the JSON that comes back, and alerts your team only after a second region confirms that something is wrong.
What API monitoring catches that a ping does not
An API can be reachable and still broken. The load balancer answers, but every request returns 503 from an unhealthy pool. Authentication works, but tokens issued since the last deploy are rejected. The endpoint returns 200 with an empty list because a background sync stopped. The response is correct, but it now takes four seconds, and the mobile app times out at three.
API monitoring sends real requests and checks real answers. It is the earliest place to see failures that customers, partners and your own frontend feel a few minutes later.
- Error status codes on endpoints your product depends on
- Responses slower than your threshold, measured per request and as percentiles
- Missing or wrong fields in the JSON body
- Broken authentication on login and token endpoints
- Changes in behavior between API versions
- Expiring certificates on API hostnames
API checks you can configure
| Setting | What you can set |
|---|---|
| Method | GET, POST, PUT, PATCH, DELETE, HEAD |
| URL | Any public HTTPS or HTTP endpoint, including versioned paths such as /v1/ and /v2/ |
| Headers | Any custom header, such as Accept, Content-Type, an API key header or a tenant ID |
| Auth | Bearer tokens, API keys and basic auth credentials, stored encrypted |
| Body | JSON or form body for POST, PUT and PATCH requests |
| Expected status | A single code such as 200, or a range such as 200 to 299 |
| Response time | An alert threshold in milliseconds |
| Timeout | How long to wait before the request counts as failed |
| Assertions | JSON field exists, equals a value, contains a string, number within a range |
Credentials are encrypted at rest and never shown again in full after you save them. Use a dedicated read-only key or test account for monitoring, so a leaked or rotated key affects nothing else.
How API monitoring works on UptimePilot
- 01 Add an API monitor and paste the endpoint URL.
- 02 Choose the method, add headers and the auth token, and write the request body if the endpoint needs one.
- 03 Set the expected status code, a response time threshold and a timeout.
- 04 Add assertions on the JSON response. For a health endpoint, "status" equals "ok". For a list endpoint, "data" exists and "meta.total" is greater than 0. For a pricing endpoint, "plans" contains "team".
- 05 Choose the interval (every minute on Starter, every 30 seconds on Team and higher), the alert channels and an escalation step.
A failure in one region triggers an immediate recheck from the other. Only a confirmed failure marks the monitor down and sends the alert by email, SMS, Slack, Microsoft Teams or webhook. The alert includes the status code, the response time and the assertion that failed, so the person on call knows where to look first.
Monitoring auth endpoints safely
Login and token endpoints are among the most valuable things to monitor and the easiest to get wrong. Create a dedicated monitoring account with no access to real customer data. Store its password or refresh token in the encrypted credential field, not in the URL, because URLs end up in logs. If your auth endpoint locks an account after several failed logins, set the interval and the alert so a single failure does not cause a lockout loop, and exclude the monitoring account from lockout rules where your system allows it.
Rate limits and monitoring traffic
At a 30 second interval, one monitor sends 2,880 requests a day from its primary region, plus rechecks when something fails. That is small, but it can still count against a per key rate limit. Give monitoring its own key, so its usage is visible and separate, and so customer traffic never triggers a 429 because of the monitor. If your API returns rate limit headers, an assertion on the remaining quota can warn you before a client hits the limit.
Versioned endpoints
When you run /v1/ and /v2/ side by side, monitor both. Old versions often break quietly, because nobody on the team uses them anymore while a partner integration still depends on them. Group monitors per version or per client, so reports and alerts follow the same structure as your contracts.
Timeouts, thresholds and percentiles
Set the timeout at the point where your slowest legitimate client gives up, often 10 seconds for server to server calls and lower for interactive frontends. Set the response time threshold above the normal p95, so ordinary variation does not page anyone. UptimePilot stores every result and shows p50, p95 and p99 over time, which makes slow drift visible weeks before it turns into timeouts. See website performance monitoring for how to choose these numbers, and the api monitoring checklist for assertions worth adding to every endpoint.
APIs as part of a wider setup
API checks sit next to the rest of your monitoring. Pair them with website monitoring for the pages that call the API, ssl certificate monitoring for API hostnames, and heartbeat checks for the workers behind the API. For a series of calls that make up one user flow, see synthetic monitoring. Link API monitors to components on your status page, so partners see an "API" outage the moment it is confirmed.
Which plan fits your API monitoring
| Plan | Monitors | Interval | Team members | Monthly, or billed yearly |
|---|---|---|---|---|
| Starter | 50 | 1 minute | 3 | $49, or $24 per month yearly |
| Team | 200 | 30 seconds | 10 | $99, or $49 per month yearly |
| Business | 1,000 | 30 seconds | 25 | $249, or $124 per month yearly |
| Enterprise | 3,000 | 30 seconds | 100 | $599, or $299 per month yearly |
API checks with assertions are included on every plan. Team adds the monthly SLA PDF, which suits API products with uptime commitments in their contracts. Business adds the REST API, so you can create monitors and incidents from your deployment pipeline. Compare everything on pricing.
01
Which HTTP methods does API monitoring support?
GET, POST, PUT, PATCH, DELETE and HEAD, with custom headers and a JSON or form body.
02
How are API keys and tokens stored?
Credentials are encrypted at rest and are not shown in full after saving. Use a dedicated key or test account for monitoring, so it can be rotated without affecting anything else.
03
What kinds of JSON assertions can I add?
You can assert that a field exists, that it equals a value, that it contains a string, or that a number falls within a range. Several assertions can run on the same response.
04
Will monitoring count against my rate limits?
It can, because probes are real requests. One monitor at a 30 second interval sends 2,880 requests a day from its primary region. A separate monitoring key keeps that usage visible and away from customer limits.
05
Can I monitor private or internal APIs?
UptimePilot checks endpoints reachable from the public internet. For internal services, expose a protected health endpoint, or use heartbeat monitors where your internal job reports to UptimePilot.
06
How fast will I hear about an API failure?
With 30 second checks, a confirmed failure usually reaches you within about a minute, including the recheck from the second region. On Starter, with 1 minute checks, within about two minutes.
Put assertions on the endpoints that matter
Add your health endpoint, your login endpoint and your busiest read endpoint. UptimePilot starts checking them from two regions right away.