Monitoring a REST API is not the same as monitoring a website. A website either loads or it doesn't. An API can return 200 with a malformed response body, pass authentication on the wrong endpoint, silently degrade its response time, or break a versioned route while the primary route stays healthy. In 2026, with microservices architectures, third-party API dependencies, and distributed consumers, REST API monitoring requires a more precise approach.
This guide covers what to monitor, how to assert correctly, and how to implement it in Vigilmon.
What REST API Endpoints to Monitor
Not all endpoints need monitoring. Prioritize by impact and failure mode:
Always monitor:
- Health check endpoint —
/health,/status,/ping, or equivalent. This is a purpose-built signal. If it fails, everything is affected. - Authentication endpoint —
/auth/token,/oauth/token,/login. If auth breaks, every authenticated user is locked out. - Primary read endpoint — the endpoint your heaviest consumers call. For most APIs, this is a list or search endpoint:
GET /api/v1/products,GET /api/v1/users. - Critical write path — the endpoint that drives revenue or core functionality:
POST /api/v1/orders,POST /api/v1/payments,POST /api/v1/submissions.
Monitor if feasible:
- Webhook delivery endpoint — if your API accepts webhooks, the receiver must be available
- Third-party integration endpoints — external APIs your service depends on
- Background job trigger endpoints — if an HTTP call initiates an async process
Skip or defer:
- Low-traffic, non-critical endpoints where failure has limited blast radius
- Endpoints that require complex multi-step auth flows to reach
- Internal admin endpoints not called by external consumers
HTTP Status Code Assertions vs Response Body Checks
These are two different layers of validation. Use both.
Status Code Assertions
The status code tells you whether the server responded correctly at the protocol layer. Set these based on what your endpoint should return:
| Endpoint type | Expected status |
|--------------|----------------|
| Successful GET | 200 OK |
| Health check | 200 OK |
| Unauthenticated API root | 401 Unauthorized |
| Non-existent resource probe | 404 Not Found |
| Rate-limited endpoint (expected throttle) | 429 Too Many Requests |
A 500 on any of these is an alert. A 502 or 503 means your upstream (load balancer, container orchestrator, reverse proxy) is failing even before your application code runs — a different failure mode.
In Vigilmon, set Expected status code on every monitor. The default is 200, but for endpoints like your unauthenticated API root that intentionally return 401, update this field to avoid false alerts.
Response Body Keyword Checks
Status 200 alone is not enough. An API can return 200 with:
- An empty body (
{}or[]) indicating an upstream failure - A cached stale response from a broken cache layer
- An error message in JSON while still returning 200 (
{"error": "database timeout"}) - A completely wrong content type (HTML error page from nginx instead of JSON)
Add a body keyword check that matches content unique to a healthy response:
// Vigilmon: Expected body contains
"status":"ok"
Or for a paginated list endpoint:
"data":[
This confirms JSON structure is intact. Even a minimal keyword check catches cases where a 200 is returned with broken content.
In Vigilmon, the Expected body contains field accepts a plain string — it's checked as a substring of the response body. Keep it short and stable: something present in every healthy response that wouldn't appear in an error response.
Latency Monitoring: Response Time Thresholds
REST APIs have performance contracts, even informal ones. A GET /products endpoint that normally responds in 120ms but starts taking 4 seconds is degraded, not down — but it's degrading your users' experience and may be the leading indicator of an imminent 500 cascade.
Set response time thresholds on monitors for latency-sensitive endpoints:
- Warning threshold: 2× the baseline p95 response time
- Critical threshold: the point at which SLO breach begins (often 5× baseline, or an absolute ceiling like 3000ms)
In Vigilmon, configure these under Response time threshold in monitor settings. Warnings don't page your on-call; they show as amber in the dashboard and appear in next-check summaries. Critical thresholds trigger the same alert path as downtime.
Vigilmon's response time history chart with color-coded latency bands (green / yellow / red) gives you visual baselines across time periods. Use this to set realistic thresholds based on observed behavior, not guesses.
Handling Authentication Headers in Monitors
Most production REST APIs require authentication. Vigilmon supports custom HTTP headers on monitors, which means you can include API keys, Bearer tokens, or Basic auth credentials directly in the monitor configuration.
API key header:
X-API-Key: your-api-key-here
Bearer token:
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Basic auth:
Authorization: Basic <base64(username:password)>
Important caveats for authenticated monitoring:
- Use a dedicated monitoring API key — create a read-only key or a monitoring-specific service account. Don't use production user credentials.
- Token rotation: if you use short-lived JWTs (e.g., 1-hour TTL), your monitor will start returning 401s after token expiry. Use long-lived tokens or API keys that don't expire for uptime monitoring.
- Monitor the auth endpoint separately — if your auth endpoint is down, every authenticated monitor will fail simultaneously. Monitoring the auth endpoint itself tells you whether failures are an auth problem or a service problem.
If your API uses OAuth2 client credentials, consider a lightweight proxy endpoint that exchanges credentials and forwards the request — though most monitoring use cases are simpler than this and a long-lived API key is more practical.
Monitoring Versioned APIs
Versioned APIs (/api/v1/, /api/v2/) require explicit monitoring for each version that has active consumers. Common failure modes in versioned APIs:
- V1 works; V2 is deployed broken
- A middleware change breaks both versions simultaneously but in different ways
- A deprecated V1 endpoint is accidentally removed while consumers still call it
Monitor each active version separately. If /api/v1/health and /api/v2/health both exist, create a monitor for each. Set alerts so a failure in either version triggers immediately.
When deprecating a version, don't remove the monitor until consumer traffic has confirmed migration is complete. Vigilmon's response time history gives you traffic signal evidence: if the V1 monitor is returning 404s and you see it happening, you know consumers are still hitting it.
For sunset-announced API versions, track the deprecation date in a calendar or issue tracker and set a reminder to verify the monitor can be decommissioned.
Vigilmon Implementation: A Reference Monitor Set
Here's a practical monitor set for a typical REST API service:
| Monitor | URL | Status | Body check |
|---------|-----|--------|-----------|
| Health | /api/health | 200 | "status":"ok" |
| API root (unauthed) | /api/v2/ | 401 | "message" |
| Primary read (authed) | /api/v2/products | 200 | "data":[ |
| Auth endpoint | /api/auth/token | 200 | "access_token" |
| Critical write (probe GET) | /api/v2/orders | 200 | "orders" |
Add custom headers for authenticated monitors. Set response time thresholds at the warning level for your primary read endpoint and at the critical level for your auth and write paths.
Check interval: 1 minute for production APIs. 5 minutes for staging.
Multi-Region Consensus: Why It Matters for API Monitoring
Single-probe API monitors generate false positives. An API probe running from a single data center in US-East will report your EU-deployed API as "down" if a transient BGP route flap affects connectivity between that probe and your region — even though EU users are unaffected.
Vigilmon's multi-region consensus checks every monitor from multiple probe nodes simultaneously. An alert fires only when multiple independent regions confirm failure. For APIs deployed in specific regions, this matters: a regional network event affecting only one probe location stays silent, while a genuine application failure affecting all regions triggers immediately.
Putting It Together
REST API monitoring done right has three layers:
- Status code assertion — confirms the server responded correctly at the protocol level
- Response body check — confirms the application returned valid content, not a masked error
- Latency threshold — detects degradation before it becomes downtime
All three layers run on every Vigilmon check, from multiple regions, with consensus-based alerting. Set up your monitors at vigilmon.online — the free tier covers 5 monitors with 5-minute check intervals, which is enough to get full health + auth + primary endpoint coverage on a single API service.
Start monitoring your REST APIs free — no credit card required: vigilmon.online