A 200 that returns an error is still down.

An API can be up and still broken. A load balancer answers, the status code is 200, and the body says the database connection failed. Your mobile app, your partners and your own frontend all see an error, and a plain uptime check sees nothing wrong.

API monitoring in Uptimecheck uses the same HTTP(S) monitors as website uptime monitoring, with the options an API needs.

What you can configure

• Method: GET, POST, PUT, PATCH, DELETE or HEAD.
• Headers: send an API key, an Accept header or a custom user agent.
• Body: post a JSON payload to test a write path.
• Basic auth: check endpoints behind HTTP authentication.
• Expected response: fail the check when the response does not contain what you expect.
• IPv6: confirm the endpoint answers over IPv6 as well as IPv4.

Which endpoints to monitor first

Start with the requests that make money or block users. For an online store that is the cart, checkout and payment callback. For a SaaS product it is login, the main read endpoint and any webhook you receive from a payment provider. The API monitoring checklist lists what to cover and how often.

A typical setup for lumenanalytics.io

• GET /health every minute, expecting "status":"ok".
• POST /v1/events with a small test payload and an API key header.
• GET /v1/reports with basic auth, alerting when the response time stays high.

Know when an endpoint slows down

Checks run every minute from Europe, and response times are stored per check, so you can see that the reports endpoint went from 90 ms to 2.4 s at 14:00, while the health check stayed flat. A failed check is run again a few seconds later before an incident opens, which keeps a single dropped request from paging the team.

Alerts and automation

When an endpoint fails, alerts go out by email, Slack, Discord, Telegram, Microsoft Teams or webhook, on every plan. A webhook can trigger your own incident tooling. You can also manage monitors from code: the REST API creates and updates monitors from your deploy pipeline, so a new endpoint gets a monitor the day it ships.

Monitor dependencies, not only your own code

Your API depends on others: a payment provider, an email service, a search index. When one of them fails, your endpoint may still answer while the feature behind it is broken. Add monitors for the third-party endpoints you rely on, or for your own endpoints that exercise them, and you can tell a customer within minutes whether the problem is yours or upstream.

Keep test traffic safe

Use a dedicated test account or API key for monitoring requests, and make write checks idempotent, so a POST every minute does not fill your database with test records. Tag monitoring traffic with a custom user agent header so it is easy to filter out of your own analytics and logs.

For background jobs that do not expose an endpoint, use heartbeats instead. See all limits on the pricing page.