Reachable is not the same as correct

API monitoring is the practice of calling your HTTP endpoints on a schedule from outside your infrastructure and checking that the response is correct, not just that it arrived. A monitor sends a real request, then asserts on the status code, the response time, the headers, and the body. Because the request comes from outside, it exercises DNS, TLS, your CDN, your load balancer, your auth layer, and your application in the same order a customer would.

Uptime monitoring answers one question: is the endpoint reachable. API monitoring answers a harder one: is the endpoint still doing its job. An API check sends a real request with a body, headers, and authentication, then validates the payload it gets back. If you only need reachability on a public URL, uptime monitoring is the cheaper and simpler tool, and Checkly does that too.

Five sources are available on every assertion: the status code, the JSON body addressed with JSONPath, the raw text body, the response headers, and the total response time in milliseconds. Headers and text bodies can be matched with regular expressions. Checkly reads up to 25MB of the response body for assertions.

Yes. Setup scripts run before the request, so you can fetch an OAuth token, sign an HMAC request, or seed test data using the real auth path a client would take. Teardown scripts run after the response lands and before assertions are evaluated, which is where you delete test records or scrub fields you are not allowed to store. Secrets come from encrypted environment variables. Endpoints that require mutual TLS are supported through client certificates.

Yes, two ways. In the app, the API check creator imports a Swagger 2.0 or OpenAPI spec and lets you pick which paths to turn into checks, carrying over names, tags, headers, and query parameters. In code, the spec is just JSON: map over its paths in a check file and generate one monitor per route, so adding a route to the spec adds a monitor on the next deploy. You can also paste a cURL command to build a check from it.

From every 10 seconds to every 24 hours, set per check. Checks run from 22 public locations across North America, Europe, Asia Pacific, South America, the Middle East, and Africa, and from private locations you host inside your own network for internal services.

Yes. A GraphQL endpoint is an HTTP POST with a query in the body, so it is an ordinary API check: send the query, then assert on the JSON body with JSONPath. That matters more than usual for GraphQL, because a failed resolver typically returns 200 with an errors array rather than an HTTP error.

The failed run is retried with the strategy you configured, so a network blip does not page anyone. If it is real, the alert routes to the channels that check or group subscribes to, and degraded can route separately from failed. The result keeps the full request and response, per phase timing for DNS, TCP, first byte, and download, and, when traces are enabled, the OpenTelemetry spans from the services behind the request. Rocky AI reads all of that and names the likely cause.