Skip to content

API monitoring for the endpoints your services depend on.

Follow the availability and latency of public HTTP API endpoints, with incident and recovery history when responses stop behaving as expected.

Illustrative example · Demo data
GET /api/health
api.example
{
  "status": "ok"
}
  1. 01200 OK · 142 ms
  2. 02200 OK · 840 ms
  3. 03503 · Service unavailable
  4. 04200 OK · 156 ms

Fictional sequence. Animation timing is not check cadence or a performance promise.

01

Start with a public health endpoint

Point an HTTP monitor at a publicly reachable endpoint such as /api/health. Track the expected response status without building a separate monitoring dashboard for every service.

02

See latency alongside availability

A successful response and a fast response are different observations. Compare response times over your selected period and review incidents around a deployment or dependency failure.

03

Know the scope of the check

This is public HTTP endpoint monitoring. It is not an authenticated API test suite, request-script runner, or a promise of POST, PUT or GraphQL testing. Keep private endpoints and credentials out of monitor URLs.

In practice

Where this signal earns its place.

  • Public health checks for a web service.
  • Read-only public endpoints used by your website.
  • Response-time comparisons before and after a release.

A closer look

Can I monitor a private API?

These monitors are intended for publicly reachable HTTP endpoints. Do not add internal network targets or credentials to URLs.

What happens when an endpoint recovers?

Recovery is recorded in the incident history and can trigger a recovery email when notifications are enabled.

Connect the context

Related signals

All features

Start monitoring

Know about downtime before your customers do.

Add your first monitor and keep website availability, performance and incident history in one clear place.

7-day Starter trial · No credit card required · Starts with your first monitor