API monitoring: 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 calls your endpoints on a schedule and checks both that they answer and that the answer is right. In Uptimecheck it 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, HEAD or OPTIONS.
• Headers: up to 20, such as an API key, an Authorization header or a custom user agent.
• Body: post a JSON payload to test a write path.
• Expected status: codes or ranges, such as 200-299 or 201.
• JSON and header checks: up to 10 checks that must all hold, such as $.status equals ok.
• Keyword: text the response must or must not contain.
• Timeout and slow limit: fail after up to 30 seconds, and get a slow alert when responses stay above your limit.

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, and our guide to health check endpoints shows what a good one returns.

A typical setup for lumenanalytics.io

• GET /health every minute, with a JSON check that $.status equals ok.
• POST /v1/events with a small test payload and an API key header.
• GET /v1/reports with an Authorization header and a slow alert at 1,500 ms.

Know when an endpoint slows down

Uptimecheck checks from Stockholm, London and New York, and confirms every failure from a second location before an incident opens, which keeps a single dropped request from paging the team. Response times are stored per check and split into DNS, connect, TLS, server and download, so you can see that the reports endpoint went from 90 ms to 2.4 s at 14:00, that the time went to the server phase, and that the health check stayed flat.

When one request is not enough

Many API problems only show up in a sequence: log in, get a token, use it. A flow monitor runs up to 10 steps in order, saves a value such as a token or an order id from one step and uses it in the next. Secrets such as passwords are encrypted and never shown again.

Alerts and automation

When an endpoint fails, alerts go to email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks and push notifications on your phone, on every plan. Webhooks are signed, so your own tooling can verify where they came from. You can also manage monitors from code: on Professional and Business, 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 hosting platform. When one of them fails, your endpoint may still answer while the feature behind it is broken. Add monitors for the endpoints that exercise them, and follow the status pages of suppliers such as Klarna, Shopify, Cloudflare and OpenAI with third-party monitoring. Then 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 cron job monitoring instead.

Plans start at €9 per month billed yearly or €12 billed monthly, excl. VAT. See all limits on the pricing page, or start a 14-day free trial without a card.