How to Monitor API Uptime
How to Monitor API Uptime
A website monitor pings a URL and checks for a 200. That works for a marketing page. It does not work for an API.
An API can return 200 while being completely broken. A misconfigured route returns 200 with an empty body. An authentication endpoint returns 200 with {"error": "invalid token"}. A payment API returns 200 in 4.2 seconds - technically up, practically unusable.
Monitoring API uptime properly means checking not just whether the endpoint responds, but whether it responds correctly, completely, and fast enough to be useful. This guide covers how to do that.
What API uptime monitoring actually checks
Status code
The baseline. Your monitor sends a request and verifies the response code matches what you expect.
For most API endpoints, that is 200. But not always:
- A
DELETE /resource/:idshould return 204, not 200. - A redirect endpoint should return 301 or 302.
- A health check that returns 204 is passing - a monitor expecting 200 would falsely flag it as down.
Configure the expected status code per endpoint, not globally. A monitor that marks 204 as a failure will alert you on a working endpoint every time it runs.
Response body
Status codes tell you whether the server responded. The response body tells you whether the application is actually working.
Two scenarios where body matching matters:
Partial failures. A REST API that connects to a database can return 200 while the database connection is broken. The response body might contain {"status": "degraded"} or an empty array where data should be. Without body matching, your monitor sees 200 and passes.
Cached errors. A CDN or reverse proxy can serve a cached error page with a 200 status code. The page says "Service Unavailable" in the body, but the status code is 200.
Configure your monitor to check for a specific string in the response body. For a health check endpoint, that might be "status":"ok". For a data endpoint, it might be a field name that should always be present in a valid response.
Response headers
Headers carry important signals that body matching alone misses.
Content-Type validation catches a server that is returning HTML error pages instead of JSON - common when a 500 gets intercepted by a web server and served as an HTML error page before it reaches your application. If your API should always return application/json and suddenly returns text/html, something upstream broke.
Cache-Control and X-Cache headers can reveal whether you are monitoring a live endpoint or a cached response. If you are seeing suspiciously consistent response times across every check, verify you are not hitting a cached layer that is masking a broken origin.
Latency thresholds
A slow API is a broken API for anyone who depends on it.
Latency thresholds let you fail a check if the response time exceeds a limit you define - regardless of the status code or body content. If your payment API normally responds in 80ms and suddenly takes 3 seconds, that is a degradation worth alerting on, even if every response is technically a 200.
Set thresholds based on your actual baseline, not an arbitrary number. Run your monitor for a week, observe the P95 response time, and set your alert threshold at roughly 3x that value. If your P95 is 150ms, a threshold of 400-500ms catches real degradation without false positives from normal variance.
Authentication in API monitors
Most production APIs require authentication. Your monitor needs to send the right credentials or it will always get a 401 and alert you on a working endpoint.
Three common patterns:
Bearer token in the Authorization header. Add Authorization: Bearer <token> to your monitor's request headers. Use a dedicated monitoring token with read-only permissions - not a production user token, and not an admin credential.
API key in a header or query parameter. Some APIs expect X-API-Key: <key> or ?api_key=<key>. Check your API's authentication documentation and configure the header or parameter accordingly.
Basic authentication. Username and password base64-encoded in the Authorization: Basic <encoded> header. Most monitoring tools handle this natively - you enter the username and password and the tool encodes them.
A few principles for monitoring credentials:
- Create a dedicated monitoring account or token with the minimum permissions needed to make the check work.
- Rotate the token on the same schedule as your other service credentials.
- Do not use a credential that, if compromised, would allow write access to production data.
What endpoints to monitor
Not every endpoint needs a monitor. Start with the ones that, if broken, immediately affect users.
Health check endpoint. If your API has a /health or /status endpoint, monitor it first. It is designed for this purpose and typically checks database connectivity, external service dependencies, and basic application state. A broken health check is a clear signal that something fundamental is wrong.
Authentication. A broken login endpoint blocks every user from accessing your product. Monitor your primary auth endpoint with a test account, verify the response contains an expected token field.
Core read operations. The GET requests your users make most frequently. If your API serves a dashboard, the endpoint that powers the main dashboard view is a high-priority monitor candidate.
Webhooks and integrations. Webhook delivery failures are silent - your system thinks it sent the event, but the receiving end never processed it. Monitor your webhook endpoints separately and consider heartbeat monitoring for delivery confirmation.
Payment and billing flows. A broken payment endpoint has direct revenue impact. Monitor it frequently, with a short check interval.
Setting up API monitoring on Nodown
Nodown's monitoring is built for exactly this workflow. Each monitor is configurable at the request level: method, URL, headers, expected status code, body keyword match, and latency threshold.
Here is the setup for a typical REST API endpoint:
1. Create a new HTTP monitor. Enter the full endpoint URL. Choose the HTTP method - GET, POST, PUT, or DELETE depending on what you are checking.
2. Add request headers.
Add your Authorization header with the monitoring token, the Content-Type header if you are sending a body, and any API-specific headers your endpoint requires.
3. Set the expected status code. Enter the status code you expect for a healthy response. 200 for most endpoints, 204 for delete or action endpoints, 201 if you are monitoring a creation endpoint in a non-destructive way.
4. Configure a keyword check.
Enter a string that must appear in the response body for the check to pass. For a JSON API, use a key that should always be present - "id", "status", "data" - rather than a value that might change between responses.
5. Set a latency threshold. Enter the maximum acceptable response time in milliseconds. Leave it blank if you only care about availability, not performance.
6. Choose a check interval. 30 seconds for critical production endpoints. 1 minute for secondary endpoints. The shorter the interval, the faster your team knows about a failure.
Nodown confirms failures across at least three of its 14 monitoring regions before triggering an alert. A single failing check from one location does not alert you - this eliminates false positives from transient network issues between a single monitoring server and your endpoint.
7. Configure alert channels. Route alerts to Slack, Discord, PagerDuty, or any other channel your team uses. For critical endpoints, route to both a Slack channel and your on-call rotation. For secondary endpoints, email is sufficient.
A Slack alert for a failed API monitor looks like this: the endpoint URL, the failure reason (unexpected status code / keyword not found / latency exceeded), the check timestamp, and a link to the monitor dashboard. Your team has everything they need to start investigating within seconds of the alert firing.
See how Nodown integrates with Slack
Common mistakes in API monitoring
Monitoring only the root URL. GET / tells you the server is alive. It does not tell you whether your database is reachable, your authentication is working, or your core endpoints are responding correctly. Monitor the endpoints users actually call.
Using a production user account as the monitoring credential. If that account is deleted, suspended, or rate-limited, every monitor tied to it starts alerting. Use a dedicated service account.
Setting the check interval too long. A 10-minute interval on a payment API means up to 10 minutes of undetected downtime per incident. For revenue-critical endpoints, 30 seconds is the right starting point.
Not matching the response body. A 200 with a broken body is a passing check with a broken API. Body matching is not optional for APIs that return structured data.
Ignoring latency. A 200 in 8 seconds is not a passing check for most production APIs. Set a latency threshold. If you do not know what threshold to use, monitor without one for a week, observe the baseline, and set it from real data.
API monitoring is not a one-time setup. As your API evolves - new endpoints, changed authentication, updated response schemas - your monitors need to evolve with it. Treat your monitor configuration as part of your deployment checklist: when a new endpoint ships, a monitor ships with it.
Start monitoring your API for free on Nodown
Last updated: May 2026.