API Monitoring Best Practices: A Developer's Guide

APIs power everything: your mobile app talks to APIs, your integrations depend on APIs, your partners consume your APIs, and your microservices communicate through APIs. When an API fails, the blast radius extends far beyond a single endpoint.

Yet many teams still monitor APIs the same way they monitor websites — a simple HTTP GET that checks for a 200 status code. That is not enough. This guide covers how to monitor APIs properly.

Why API Monitoring Is Different from Website Monitoring

Website monitoring asks: “Does this URL return a successful response?”

API monitoring needs to ask:

Does the endpoint return the correct status code?
Is the response body valid and complete?
Are the response headers correct?
Is the response time within acceptable limits?
Does authentication work?
Do POST/PUT/DELETE operations succeed?
Does the API handle edge cases gracefully?

A website that returns 200 with a broken page is a problem. An API that returns 200 with an error in the response body is a worse problem because it silently corrupts data for every consumer.

Setting Up Effective API Monitors

Monitor the Critical Path

Start with the endpoints that matter most:

Health check endpoint: Your API’s self-reported health status
Authentication: Login, token refresh, token validation
Core read operations: The most-used GET endpoints
Core write operations: POST/PUT endpoints that create or modify data
Search and query: Complex query endpoints that are performance-sensitive

Health Check Endpoints

Every API should expose a health check endpoint that reports the status of its dependencies:

// Express.js health check example
app.get('/api/health', async (req, res) => {
  const checks = {
    database: await checkDatabase(),
    cache: await checkRedis(),
    queue: await checkMessageQueue(),
    storage: await checkS3(),
  };
  
  const healthy = Object.values(checks).every(c => c.status === 'ok');
  
  res.status(healthy ? 200 : 503).json({
    status: healthy ? 'healthy' : 'degraded',
    timestamp: new Date().toISOString(),
    checks,
  });
});

Monitor this endpoint with response body validation:

{
  "type": "api",
  "url": "https://api.example.com/api/health",
  "method": "GET",
  "expectedStatus": 200,
  "expectedBody": "\"status\":\"healthy\"",
  "interval": 30
}

Authentication Endpoints

Monitor your auth flow with a dedicated test account:

{
  "type": "api",
  "url": "https://api.example.com/auth/token",
  "method": "POST",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "client_id": "monitoring-client",
    "client_secret": "${MONITORING_SECRET}",
    "grant_type": "client_credentials"
  },
  "expectedStatus": 200,
  "expectedBody": "access_token"
}

Use a dedicated service account with minimal permissions. Do not use a real user’s credentials for monitoring.

Response Time Thresholds

Set response time thresholds based on your API’s performance requirements:

Endpoint Type	Target p95	Alert Threshold
Health check	< 100ms	> 500ms
Simple read	< 200ms	> 1000ms
Complex query	< 500ms	> 2000ms
Write operation	< 300ms	> 1500ms
File upload	< 2000ms	> 5000ms

Alert when response times consistently exceed thresholds, not on individual slow requests. A single slow response might be a network hiccup; sustained slowness indicates a real problem.

REST API Monitoring Patterns

Pattern 1: Status Code Validation

The minimum viable API monitor:

{
  "url": "https://api.example.com/v1/users",
  "method": "GET",
  "headers": { "Authorization": "Bearer ${TOKEN}" },
  "expectedStatus": 200
}

Pattern 2: Response Body Validation

Check that the response contains expected fields:

{
  "url": "https://api.example.com/v1/users",
  "method": "GET",
  "headers": { "Authorization": "Bearer ${TOKEN}" },
  "expectedStatus": 200,
  "expectedBody": "\"users\""
}

Pattern 3: Write Operation Monitoring

For POST/PUT endpoints, create and clean up test resources:

{
  "url": "https://api.example.com/v1/healthcheck/write-test",
  "method": "POST",
  "headers": {
    "Authorization": "Bearer ${TOKEN}",
    "Content-Type": "application/json"
  },
  "body": { "test": true, "timestamp": "${TIMESTAMP}" },
  "expectedStatus": 201
}

Design a dedicated write-test endpoint that accepts and immediately discards test data, so your monitoring does not pollute production data.

Pattern 4: Pagination and List Endpoints

List endpoints can break in subtle ways (returning empty results, wrong sort order, missing pagination):

{
  "url": "https://api.example.com/v1/products?limit=1",
  "method": "GET",
  "expectedStatus": 200,
  "expectedBody": "\"total\""
}

GraphQL API Monitoring

GraphQL introduces specific monitoring challenges:

The 200 Problem

GraphQL always returns HTTP 200, even for errors. The error information is in the response body:

{
  "data": null,
  "errors": [{
    "message": "Authentication required",
    "extensions": { "code": "UNAUTHENTICATED" }
  }]
}

Your monitoring must check the response body, not just the status code.

Monitoring GraphQL Effectively

Send actual queries and validate the response:

{
  "type": "graphql",
  "url": "https://api.example.com/graphql",
  "query": "query { systemHealth { status database cache } }",
  "expectedBody": "\"status\":\"ok\"",
  "interval": 30
}

StatusApp’s GraphQL monitor type handles this natively — it sends your query and validates the response structure, catching both errors and unexpected response shapes.

Query Complexity Monitoring

Monitor representative queries of varying complexity:

Simple query: Single-field lookup (baseline performance)
Medium query: Nested relationships (typical user query)
Complex query: Deep nesting, aggregations (worst-case performance)

Track response times across complexity levels to catch degradation in your resolver performance.

Third-Party API Monitoring

Your application depends on external APIs. Monitor them:

Payment providers: Stripe, PayPal, Square
Email services: SendGrid, Postmark, Mailgun
Cloud services: AWS, GCP, Azure service endpoints
Authentication: Auth0, Okta, Firebase Auth
CDN: Cloudflare, Fastly, CloudFront

Monitor the health or status endpoints these providers offer. When a third-party goes down, knowing immediately lets you activate fallbacks or communicate proactively with your users.

API Monitoring Anti-Patterns

Anti-Pattern 1: Monitoring Only in One Region

Your API might be healthy in US-East but failing in Asia-Pacific due to a CDN misconfiguration or regional infrastructure issue. Monitor from multiple global locations.

Anti-Pattern 2: Using Production User Credentials

Never monitor with real user credentials. Use dedicated service accounts with minimal permissions. If the monitoring credentials leak, the blast radius should be near zero.

Anti-Pattern 3: Ignoring Response Time Degradation

An API that responds in 5 seconds instead of 200ms is technically “up” but is providing a terrible user experience. Monitor response times, not just availability.

Anti-Pattern 4: No Response Body Validation

An API returning {"error": "Internal Server Error"} with a 200 status code looks healthy to status-code-only monitors. Always validate response content.

Anti-Pattern 5: Monitoring Only GET Endpoints

POST, PUT, and DELETE endpoints can fail independently of GET endpoints. A database in read-only mode will serve GET requests fine while all writes fail.

Building an API Monitoring Dashboard

Organize your API monitors for quick situational awareness:

Group by service: User API, Payment API, Notification API
Show response time trends: Are any endpoints getting slower?
Display uptime percentages: Which services are most reliable?
Track incident frequency: Which endpoints fail most often?

StatusApp’s dashboard provides this view out of the box, with historical analytics that help you identify patterns and prevent future issues.

Start monitoring your APIs the right way. Try StatusApp free with built-in API and GraphQL monitoring support.