Your API returns a 200. Your dashboard is green. Meanwhile, your mobile app is showing blank screens because the /api/v1/feed endpoint is returning an empty array instead of actual data. The status code is fine. The response body is broken.

APIs are the backbone of every modern product. Mobile apps, SPAs, third-party integrations, webhooks -- they all depend on your API being available, fast, and correct. If your API goes down, everything downstream goes down with it. And internal health checks are not enough: they run inside your infrastructure, behind your load balancer, often on the same network. External monitoring catches the failures that internal checks never see.

This guide covers how to set up comprehensive API endpoint monitoring: what to monitor, how to handle authentication, why response time matters, and how to automate the whole thing. If you are new to monitoring in general, start with our uptime monitoring setup guide first.

What API monitoring actually covers

Basic uptime monitoring asks one question: did the server respond with a 200? API monitoring asks three:

  • Availability -- is the endpoint reachable and returning the expected status code?
  • Response time -- how long does it take? A 200 that takes 12 seconds is functionally down for most clients.
  • Correctness -- does the response body contain the data it should? A 200 with an empty body or an error message wrapped in a success response is a silent failure.

Most outages are not total crashes. They are partial failures: one endpoint is slow, another returns stale data, a third works fine from your office but times out from Asia. Effective API monitoring catches all of these.

Types of API endpoints to monitor

Not every endpoint needs the same monitoring strategy. Here is what to prioritize and why.

Health check and status endpoints

The /health or /status endpoint is the starting point. It should verify that your application can reach its database, cache, and any critical external services. Monitor this with a simple GET check expecting a 200 response. If your health endpoint returns a JSON body like {"status":"ok","db":"connected"}, add keyword monitoring to verify the body contains "status":"ok" -- not just that the endpoint responded.

Authentication endpoints

If users cannot log in, your product is down. Monitor your /auth/login or /oauth/token endpoint with a POST request containing test credentials. Expect a 200 or 401 (depending on whether you use real credentials or intentionally invalid ones). The key is confirming the auth service is running and responding, not that any specific account works.

Core CRUD endpoints

Your most-used read endpoints -- the ones that power your main UI or your public API -- need monitoring. These are the GET /api/v1/users, GET /api/v1/products, GET /api/v1/orders endpoints that your frontend calls on every page load. If they are slow or broken, the whole experience degrades.

Webhook receivers

Webhook endpoints are easy to forget because they are not user-facing. But if your Stripe webhook handler is down, you stop processing payments. If your GitHub webhook handler is down, your CI/CD stops triggering. Monitor these with POST requests that include a minimal valid payload. A healthy webhook receiver should return a 200 quickly, even if it queues the actual processing for later.

Third-party API dependencies

If your product depends on a third-party API (payment processor, email provider, mapping service), monitor their status endpoints too. You cannot fix their outages, but you can detect them before your users do and activate maintenance windows or failover logic proactively.

GraphQL endpoints

GraphQL APIs expose a single endpoint, usually /graphql. A simple GET or OPTIONS check only tells you the server is running. For real monitoring, send a POST with a lightweight query in the request body -- something like {"query":"{ __typename }"} -- and verify the response contains "data". This confirms the GraphQL execution engine is actually working, not just that the HTTP server is alive.

Setting up API monitors in CronAlert

CronAlert supports all the HTTP methods, custom headers, request bodies, and response validation you need to monitor API endpoints properly. Here is how to configure each type.

GET monitors for health checks

The simplest case. Create a monitor, set the URL to your health endpoint, choose GET as the method, and set the expected status code to 200. CronAlert will hit it every 1 or 3 minutes (depending on your plan) and alert you if the status code does not match.

POST monitors with headers and bodies

For endpoints that expect POST requests, you can configure a request body and set the Content-Type header. For a JSON API, set the header to application/json and provide a body like: 

{
  "query": "{ __typename }"
}

This works for GraphQL endpoints, webhook receivers, or any POST endpoint you need to validate.

Expected status codes

Not every healthy endpoint returns 200. A POST that creates a resource might return 201 Created. A DELETE might return 204 No Content. An auth endpoint with test credentials might return 401 Unauthorized -- and that is the expected, healthy response. Set the expected status code in your monitor to match what your endpoint actually returns when it is working correctly.

Keyword monitoring for response validation

Status codes are necessary but not sufficient. Use keyword monitoring to verify the response body contains a specific string. For a health endpoint, check for "status":"ok". For an API endpoint, check for a key that should always be present in a valid response, like "data" or "results". If the keyword is missing, CronAlert treats it as a failure and triggers an alert.

Content monitoring for deeper validation

When keyword monitoring is not granular enough, content monitoring lets you validate the structure and content of API responses more thoroughly. This is useful for catching schema changes, missing fields, or unexpected values that a simple keyword check would miss.

Monitoring authenticated APIs

Most production APIs require authentication. CronAlert lets you add custom headers to any monitor, which is how you pass credentials.

For Bearer token authentication: 

Authorization: Bearer your_api_token_here

For API key authentication (common with third-party services): 

X-API-Key: your_api_key_here

A few rules for monitoring tokens:

  • Create a dedicated monitoring token. Do not reuse a developer's personal token. If that person leaves and their token is revoked, your monitoring breaks silently.
  • Use read-only permissions. Your monitoring token should never have write access. It only needs to call GET endpoints and verify responses.
  • Set a long expiry or no expiry. Tokens that expire monthly cause monitoring gaps every time they rotate. If your auth system supports non-expiring service tokens, use one.
  • Rotate on a schedule, not in a panic. Set a calendar reminder to rotate the token quarterly. Update the CronAlert monitor header when you do.

Response time monitoring

Slow is the new down. An API that takes 8 seconds to respond is technically "up" but practically unusable. Mobile clients will time out. Frontend apps will show loading spinners indefinitely. Users will leave.

CronAlert records the response time for every check. This data is visible in the monitor detail view and through the REST API. Use it to spot trends before they become outages:

  • Gradual slowdown -- response times creeping up over days usually means a growing dataset, missing index, or connection pool exhaustion.
  • Periodic spikes -- consistent slow responses at the same time each day often correlate with cron jobs, batch processes, or traffic peaks.
  • Region-specific latency -- an endpoint that is fast from the US but slow from Europe points to a CDN misconfiguration or a single-region deployment.

Track response times for your critical endpoints and set a baseline. If your login endpoint normally responds in 150ms and it starts taking 800ms, something has changed -- even if it is still returning 200.

Multi-region API monitoring

If your API serves users globally, monitoring from a single location is not enough. An endpoint that is healthy from Virginia might be unreachable from Singapore. DNS propagation issues, regional CDN failures, and cloud provider zone outages all cause location-specific problems that single-region checks miss entirely.

CronAlert's multi-region monitoring checks your endpoints from 5 geographically distributed locations simultaneously. You can configure alerting to trigger when a specific number of regions report failures, filtering out transient network blips while still catching real regional outages.

This is especially valuable for API endpoints because latency varies dramatically by region. An API call that takes 100ms domestically might take 600ms+ crossing the Pacific. Multi-region checks give you visibility into what your international users actually experience.

Automating monitor creation with the API

Manually creating monitors in a dashboard does not scale. If your team deploys new services regularly, you want monitors created automatically as part of the deployment process. CronAlert's REST API makes this straightforward.

Here is an example of creating a monitor from a CI/CD pipeline: 

curl -X POST https://cronalert.com/api/v1/monitors \
  -H "Authorization: Bearer ca_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Payment API - Health Check",
    "url": "https://api.example.com/health",
    "method": "GET",
    "expectedStatusCode": 200,
    "keyword": "\"status\":\"ok\""
  }'

Practical ways to integrate this:

  • CI/CD pipeline step -- add a post-deploy step that creates or updates a monitor for the deployed service. If the monitor already exists (check by name or URL), update it. If it is new, create it.
  • Infrastructure as code -- store monitor definitions in a JSON or YAML file alongside your service configuration. A script reads the file and syncs monitors via the API on every deploy.
  • Service registry integration -- if you maintain a service catalog, hook into its create/delete events to automatically provision and tear down monitors.

If your team manages monitoring collectively, set up team monitoring so everyone has visibility into the same set of monitors without duplicating effort.

Alert strategies for API monitoring

Not every API endpoint deserves the same alerting treatment. A failing health check on your payment service needs to wake someone up at 3 AM. A flaky internal reporting endpoint can wait until morning.

Structure your alerts by severity:

  • Critical (immediate, multi-channel) -- authentication, payment processing, core data endpoints. Alert via Slack, email, and webhook simultaneously. These are the endpoints where downtime directly costs money or blocks users.
  • High (immediate, single channel) -- public API endpoints, webhook receivers, partner integrations. A Discord or Slack notification is enough. Investigate within the hour.
  • Medium (batched) -- internal APIs, admin endpoints, background job APIs. Email alerts are fine. Check during business hours.
  • Low (logged only) -- development or staging APIs, experimental endpoints. Monitor them for trend data, but do not alert on every failure. Review the status page weekly.

Pair this with SSL certificate monitoring on every HTTPS endpoint. An expired certificate will take down your API just as effectively as a server crash, and it is entirely preventable with advance warning.

Putting it together

Here is a practical checklist for monitoring an API-driven service:

  1. Create a GET monitor for your health check endpoint with keyword validation on the response body.
  2. Add monitors for your 3-5 most critical API endpoints, including at least one POST endpoint if your API accepts writes.
  3. Configure custom headers with a dedicated, read-only monitoring token.
  4. Enable multi-region checks for any endpoint serving international users.
  5. Set up alert channels appropriate to each endpoint's severity -- critical endpoints get Slack + email, lower-priority ones get email only.
  6. Automate monitor creation in your CI/CD pipeline using the CronAlert REST API.
  7. Review response time trends weekly to catch degradation early.

You can also monitor the other side of the equation: if your services depend on scheduled tasks, use heartbeat monitoring to verify those cron jobs are actually running on schedule.

Create a free CronAlert account to start monitoring your API endpoints in under a minute. The free plan includes 25 monitors with 3-minute checks and email, Slack, Discord, and webhook alerts -- enough to cover the critical endpoints of most services.

FAQ

What is the difference between API monitoring and uptime monitoring?

Uptime monitoring checks whether a URL returns a successful HTTP status code. API monitoring goes further: it validates response bodies, checks response times, sends authenticated requests with headers and payloads, and verifies that endpoints return correct data -- not just that they respond. In practice, you want both. Start with basic uptime checks and layer on response validation and authenticated monitoring as your API matures.

How do I monitor an API that requires authentication?

In CronAlert, add custom headers to your monitor configuration. For Bearer token auth, add an Authorization header with the value Bearer your_token. For API key auth, add whatever header your API expects (commonly X-API-Key or Authorization). Create a dedicated monitoring token with read-only permissions and a long expiry to avoid monitoring gaps.

How often should I check my API endpoints?

For critical endpoints -- authentication, payments, core data APIs -- 1-minute intervals are recommended. You want to know within 60 seconds if something breaks. Health check endpoints and lower-priority APIs can use 3-minute intervals without much risk. CronAlert's free plan checks every 3 minutes; Pro, Team, and Business plans support 1-minute intervals.

Can I monitor POST endpoints, not just GET?

Yes. CronAlert supports GET, POST, PUT, PATCH, DELETE, and HEAD methods. For POST monitors, configure a request body (JSON, form data, or plain text) and set the appropriate Content-Type header. This is essential for monitoring GraphQL APIs, webhook receivers, and any endpoint that expects a request payload.

How do I automatically create monitors when I deploy a new service?

Use CronAlert's REST API. Add a step to your CI/CD pipeline that calls POST /api/v1/monitors with the endpoint URL, expected status code, and any custom headers. Store monitor definitions alongside your service code so they stay in sync with deployments. This eliminates the manual step of configuring monitors after every deploy.