The API Uptime Monitoring Guide 2026

APIs are the load-bearing walls of modern software. REST endpoints, GraphQL schemas, and webhook delivery systems power mobile apps, third-party integrations, revenue pipelines, and customer-facing products. When they go down — or degrade silently — the impact ripples far beyond a single failing request.

Yet most teams monitor their APIs the same way they monitor static websites: ping it, check for 200, move on. That approach misses the failure modes that actually hurt: slow responses that time out downstream consumers, correct status codes with malformed payloads, endpoints that work in one region but fail in another, and latency creep that approaches SLA breach before anyone notices.

This guide covers how to monitor REST APIs, GraphQL endpoints, and webhooks for uptime, response time, and correctness — and how to use Vigilmon to catch every meaningful failure mode before your users do.

What API Monitoring Actually Needs to Cover

API monitoring is more nuanced than uptime monitoring for a simple website. An API can be "up" by every naive measure while failing its consumers in ways that matter.

Status code monitoring

The baseline: is the endpoint returning the expected status code? A 200 means the server responded — it doesn't mean the response is correct. But a 500, 502, 503, or 429 is a clear signal that something is wrong. Monitor for unexpected status codes on every endpoint.

Don't only alert on 5xx errors. A REST API that returns 404 for a resource that should exist is broken. An authentication endpoint that starts returning 401 for valid credentials is broken. Configure expected status codes per endpoint.

Response time monitoring

A slow API is a broken API for many consumers. If your API normally responds in 80ms but starts responding in 2000ms, downstream services will time out, mobile apps will show loading spinners, and users will abandon. Response time degradation often precedes hard failures — a database query that takes 10x longer before it starts timing out completely.

Monitor response time with thresholds. Alert when response time exceeds a threshold (e.g., 1 second for a simple endpoint), and track response time history to spot trends before they become incidents.

Response content validation

A 200 with an empty body, a 200 with a JSON parse error, or a 200 with a missing required field are all failures. Without content validation, your monitoring doesn't know the difference between a healthy response and a broken one that happens to return 200.

For critical endpoints, configure response body assertions — check that specific fields exist, that the content type is correct, or that a key value matches an expected pattern.

Geographic consistency

An API can work perfectly in one region and fail in another due to DNS misconfiguration, regional deployment failures, or CDN routing issues. Monitoring from a single probe location means region-specific failures are invisible until a user in that region reports them.

Multi-region monitoring — checking your API from probe nodes in multiple geographic regions — catches regional failures that single-probe monitoring misses entirely.

Webhook delivery monitoring

Webhooks are the reverse of standard API monitoring: instead of your monitor calling your API, your system calls an external endpoint. When webhook delivery fails — because the receiver is down, returns a non-2xx response, or times out — data is lost or events queue up indefinitely. Monitor webhook receiver endpoints to ensure they're accepting requests.

REST API Monitoring

REST APIs are the most common case. Every HTTP endpoint deserves a monitor; the question is what to monitor and how.

Which endpoints to monitor

Not every endpoint needs a monitor — but every endpoint that directly affects users or downstream systems does. Prioritize:

Authentication endpoints (login, token refresh): if these fail, nothing else works
Core business logic endpoints (create order, process payment, submit form): revenue-critical
Data retrieval endpoints with high traffic (product listings, user profiles): user-facing
Webhook receivers: inbound webhook delivery is silent when broken
Health and readiness endpoints: /health, /ready, /ping

Configuring REST monitors in Vigilmon

For each REST endpoint:

Add an HTTP monitor with the endpoint URL and HTTP method
Set the expected status code — most GET endpoints expect 200, POST/PUT may expect 201 or 200
Set a response time threshold — base this on your SLA or the downstream consumer's timeout
Configure authentication if needed — add an Authorization header for protected endpoints
Add a response body assertion for critical endpoints — check for a required field in the JSON response
Set check interval to 1 minute — you want to know about failures fast

For POST endpoints that would create real data if called with a payload, either:

Use a dedicated /health endpoint that doesn't have side effects
Use a read-only equivalent (GET) that exercises the same infrastructure path
Use a test-mode parameter that the endpoint recognizes and handles without creating real data

Monitoring with authentication headers

Many APIs require authentication. In Vigilmon, add custom headers to your HTTP monitors:

Authorization: Bearer YOUR_MONITORING_TOKEN

Create a dedicated monitoring token or API key with read-only permissions. This isolates monitoring credentials from production credentials and makes it easy to rotate them independently.

GraphQL API Monitoring

GraphQL APIs present a different monitoring challenge than REST APIs. A GraphQL API has a single endpoint — typically POST /graphql — but can handle hundreds of different operation types. A 200 response doesn't mean the query succeeded: GraphQL returns 200 even for errors, putting error information in the response body.

Key differences from REST monitoring

Single URL, multiple operations: Monitor the endpoint health with a simple introspection query or a lightweight test operation
Errors are in the body: A 200 with {"errors": [...]} in the body is a failed query — configure response body assertions to check for the absence of an errors field
Schema changes can break clients silently: A field removal or type change breaks clients without any HTTP error

GraphQL monitoring in Vigilmon

Configure an HTTP monitor with:

Method: POST
URL: Your GraphQL endpoint (e.g., https://api.yourapp.com/graphql)
Body: A lightweight query that exercises core functionality without side effects:

{
  "query": "{ __typename }"
}

This is an introspection query that every GraphQL server responds to if healthy. It requires no data access and has no side effects. The expected response is a 200 with {"data": {"__typename": "Query"}}.

For more thorough monitoring, create test queries that exercise your most critical resolvers. Run these every minute from Vigilmon and assert that the response contains the expected fields and no error array.

Webhook Delivery Monitoring

Webhooks are asymmetric: your system sends requests to external endpoints, and you have no control over whether those endpoints are available. But you do control the receiver endpoints that external systems send webhooks to — and those receivers need monitoring.

Monitoring inbound webhook receivers

An inbound webhook receiver endpoint (e.g., https://api.yourapp.com/webhooks/stripe) needs to:

Return 200 quickly (webhook senders typically timeout in 5-30 seconds)
Process the payload correctly
Not return 5xx errors that cause the sender to retry indefinitely

Monitor the receiver endpoint with an HTTP monitor. Many teams add a /health sub-path to each webhook receiver that accepts GET requests and returns 200 without requiring a valid webhook payload.

Heartbeat monitoring for webhook processing jobs

Webhook receivers typically write events to a queue, and a separate processing job consumes the queue. If the processing job stops — due to a deployment error, a dependency failure, or a silent crash — events queue up indefinitely without anyone knowing.

Use Vigilmon's heartbeat monitoring to detect this. The heartbeat model: your processing job pings Vigilmon after each successful batch, and if Vigilmon doesn't hear from the job within the expected interval, it fires an alert.

# After processing a batch of webhooks
curl -X POST https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_ID

Set the heartbeat timeout slightly longer than the job's normal interval. If the job runs every 2 minutes, set the timeout to 5 minutes to allow for occasional slow batches.

Response Time Thresholds and SLA Monitoring

Response time monitoring is most useful when calibrated to your actual SLAs and consumer expectations.

Setting meaningful thresholds

Don't use arbitrary round numbers like "alert if > 1 second." Instead:

Observe baseline: Run your monitor for a week and note the p95 response time (the time exceeded by only 5% of requests)
Set warning threshold at 3x baseline: If your API normally responds in 80ms, alert when it exceeds 240ms
Set critical threshold at 10x baseline or your consumer's timeout, whichever is lower: If a mobile client times out at 5 seconds, your critical threshold should be below 5 seconds

This approach scales naturally — a fast endpoint gets a tighter threshold, a slow but stable endpoint gets an appropriately relaxed one.

Latency trends in Vigilmon

Vigilmon's response time history stores latency data over time and displays it as color-coded trend charts. This is useful for:

Spotting gradual degradation: An endpoint that drifts from 80ms to 400ms over two weeks is approaching a problem even if it never triggers an alert
Correlating incidents: "Latency spiked at 2:47 PM" gives you a timestamp to correlate with deployment logs, database metrics, and traffic patterns
Capacity planning: Sustained latency increase often indicates a resource constraint that needs attention before it becomes a hard failure

Multi-Region API Monitoring

A single-probe monitor checks your API from one location. Regional failures — a deployment that only succeeded in two of three regions, a CDN routing misconfiguration, a regional database replica that fell behind — are invisible to single-probe monitoring.

Vigilmon's consensus-based alerting uses multiple geographically distributed probe nodes. This has two benefits:

Regional failure detection: If your API is down in Europe but healthy in the US, Vigilmon detects it
False positive elimination: A transient network issue affecting one probe doesn't trigger an alert — Vigilmon requires consensus from multiple probes before firing

For APIs with global user bases, this is essential. A European user experiencing a 503 while your US monitor shows green is a real outage that your monitoring is missing.

Alert Routing for API Monitoring

Different API failures have different urgency levels. Configure notification routing to match:

Immediate page (PagerDuty/SMS):

Authentication endpoint down
Payment processing endpoint down
Core API returning 5xx

Urgent Slack notification:

Response time exceeds critical threshold
Webhook receiver returning errors
Regional failure detected

Email/low-priority Slack:

Response time in warning zone
GraphQL errors appearing occasionally
Staging environment API degraded

Getting Started with API Monitoring in Vigilmon

Vigilmon's free tier covers 5 monitors with 1-minute check intervals — start with your five most critical API endpoints. The setup for each monitor takes under two minutes:

Choose HTTP/HTTPS monitor type
Enter the endpoint URL and HTTP method
Configure expected status code and optional response body assertion
Set your response time alert threshold
Configure notification channels

Add heartbeat monitors for your webhook processing jobs and background workers to complete the picture.

Try Vigilmon free at vigilmon.online — no credit card required.

Summary

Effective API monitoring goes beyond checking that an endpoint returns 200. The failure modes that actually hurt — slow responses, malformed payloads, regional failures, webhook processing backlogs — require response time monitoring, content validation, multi-region probing, and heartbeat monitoring for background jobs. Vigilmon covers all of these in one tool, with 1-minute check intervals and multi-region consensus alerting that eliminates false positives. Start with your authentication and payment endpoints, add response time thresholds based on your observed baselines, and layer in heartbeat monitors for any background processing. That's complete API uptime monitoring.