API monitoring with failures confirmed before you are alerted

Check your endpoints with the method, headers, and status codes your clients really use, from three locations, with response time broken down by phase.

Why an API needs more than a ping

An API can answer a request and still be broken. It may return 200 with an error message in the body, respond slowly enough that clients time out, or reject requests that carry credentials while a plain request succeeds. A check that only asks whether the server is reachable misses all three.

API uptime monitoring sends the request your clients send and judges the response: the status code, the content, and the time it took. It also has to avoid crying wolf, because an alert caused by one bad network path trains people to ignore alerts.

How API monitoring works

  1. Create an HTTP monitor

    Enter the endpoint URL, choose the method, and set the check interval.

  2. Describe a healthy response

    Set the expected status codes, and optionally keywords the body must or must not contain.

  3. Checks run from three locations

    Probes in Amsterdam, US West, and Singapore send the request on your schedule.

  4. A failure is confirmed, then alerted

    A failure at one probe is retried from the others. An incident opens only when 3 probes in at least 2 regions have failed.

What you configure

An HTTP monitor can be set up to match how your API is called:

  • Method: GET, POST, PUT, DELETE, HEAD, OPTIONS, or PATCH
  • Custom headers and a request body, with Basic and Digest auth
  • Expected status codes and redirect handling; by default only 200 counts as success
  • Keyword checks of up to 20 keywords, including forbidden keywords that fail the check when found
  • A timeout, up to 60 seconds, that is shorter than the check interval
  • An optional slow response alert with your own threshold

What alerts you get

Each check records DNS, TCP, TLS, and server time separately, so an alert comes with a clue about where the time went. P50, P95, and P99 response times show the slow tail that an average hides.

Incidents and recoveries go to email, Slack, Telegram, Pushover, and webhooks, on every plan. Webhook requests can be signed with HMAC-SHA256. There is no SMS or phone-call alerting.

  • Private and internal addresses are not accepted, so the endpoint must be reachable from the internet.
  • If you use a firewall or WAF, allow the UptimeIO-Monitor/1.0 user agent.

Which plans include it

HTTP and keyword monitoring are available on every plan. Free includes 50 monitors with 5-minute checks. Pro includes 100 monitors and Scale includes 300, both with 30-second checks. Pro and Scale can also choose which locations a monitor uses.

UptimeIO also has a REST API for managing monitors and reading results, with API access on every plan.

Frequently asked questions

What is API monitoring?

API monitoring sends requests to your API endpoints on a schedule and checks the status code, response content, and response time. You are alerted when a check fails or the endpoint becomes slow.

Can UptimeIO monitor an API that needs authentication?

Yes. You can send custom headers such as Authorization or X-API-Key, and an HTTP monitor supports Basic and Digest auth. Use a dedicated, revocable credential for monitoring.

How does UptimeIO avoid false alerts for my API?

A failed check is retried from the other locations. An incident opens only when 3 probes in at least 2 regions have failed, and recovery is confirmed the same way.

Can I check that an API response contains specific content?

Yes. Keyword monitoring supports up to 20 keywords per monitor, matching any or all, with optional case sensitivity. Forbidden keywords fail the check when they are found, in the body, the headers, or both.

How often are API endpoints checked?

Every 5 minutes on the Free plan and every 30 seconds on Pro and Scale. 30 seconds is the shortest interval on any plan.

Can I monitor an API that is only reachable on a private network?

No. Private and internal addresses are not accepted, because checks run from public probe locations. The endpoint must be reachable from the internet.

Related

Start monitoring in a few minutes

Start monitoring free

Free plan · 50 monitors · No credit card required