API monitoring that checks your responses, not just your status codes

Why APIs need more than a status-code check

An API can return 200 OK while being broken: an empty list where there should be data, an error object inside a successful response, or a stale cache serving yesterday's values. API monitoring catches these by checking what the response actually contains.

Basic HTTP monitors, available on every plan, can already confirm that an endpoint responds and contains a keyword. Advanced API monitors on Starter and Team go further:

• Real requests. Use any method, set custom headers such as Authorization or Accept, and send a JSON or form body up to 64 KiB.
• Credentials kept safe. Secrets are stored encrypted at rest and referenced from headers. They are dropped automatically if a redirect points to a different origin, so a token is never leaked to another host.
• Typed assertions. Check that a substring is present, that the body matches an RE2 regular expression, or that a bounded JSONPath expression returns the expected value.

Status codes can be required exactly or as a range, for example 200–299. Every request records a timing breakdown so you can tell a slow DNS lookup from a slow database query.

Non-GET methods can change data. Uptime Tracker shows a side-effect warning when you choose POST, PUT, PATCH or DELETE, and the safest pattern is a dedicated health or test endpoint that does not create real records.

Writing useful JSON assertions

A good API assertion checks the one field that proves the endpoint is doing its job, rather than the whole response. Uptime Tracker supports bounded JSONPath expressions, so you can point at a specific value inside a JSON response.

Suppose your health endpoint returns:

{ "status": "ok", "db": { "connected": true }, "queue": { "lag_seconds": 3 } }

Useful assertions might be:

• $.status equals ok, to confirm the service reports itself healthy.
• $.db.connected equals true, to catch a lost database connection that the web tier hides.
• A regex such as "lag_seconds":\s*[0-9]\b to require single-digit queue lag.

For list endpoints, assert that a known item exists rather than checking exact counts, which change over time. For search or pricing APIs, assert on a stable reference record. Keep assertions few and specific: each one should map to a failure you would genuinely want to be woken up for.

Regular expressions use the RE2 syntax, which runs in linear time and cannot be slowed down by pathological patterns. JSONPath expressions are bounded for the same reason, so a large response can be checked quickly.

Multi-step API workflows

Multi-step API workflows on the Team plan test a sequence of requests the way a real client would, which is the only way to monitor flows that need a login or depend on earlier responses. A workflow can contain up to 10 chained HTTP requests, and values extracted from one response can be used in later steps.

A typical workflow looks like this:

1. Authenticate: POST credentials stored as encrypted secrets to /oauth/token and extract the access token.
2. Read: GET /v1/account with the token in the Authorization header and assert on the account ID.
3. Exercise the core feature: call a search or quote endpoint and assert that results are returned.
4. Clean up: if the flow creates test data, delete it in a final step.

Each step has its own assertions, and the workflow fails at the first step that does not pass, so the alert tells you exactly where the chain broke: login, permissions, or the feature itself.

Team includes 50,000 request units per month for workflows. As a rough guide, a 4-step workflow running every 5 minutes uses about 4 × 288 × 30 = 34,560 requests in a 30-day month. Run critical flows more often and less critical ones less often to stay within the allowance.

Set up an API monitor

You can monitor an authenticated API endpoint in a few minutes on Starter or Team.

1. Sign in and create a secret for your API key or token. Secrets are encrypted at rest.
2. Create an HTTP monitor and open the advanced options. Choose the method and enter the endpoint URL.
3. Add headers, referencing your secret in the Authorization header, and add a request body if needed.
4. Set the expected status code or range, then add one or two assertions on the response.
5. Choose the interval: 60 seconds on Starter or 30 seconds on Team for critical endpoints.
6. Save the monitor and confirm the first check passes.

Monitors can also be created from code. The REST API, documented with an OpenAPI spec, and the monctl CLI are available on every plan, so you can keep monitor definitions next to your service and create them from CI. See monitoring for developers and DevOps.

Remember that monitors cannot target private or internal network addresses. For an internal API, run a small script inside your network that calls the API and pings a heartbeat monitor on success.

What's included on each plan

Simple endpoint checks work on Free, authenticated API monitoring with assertions starts on Starter, and multi-step workflows are part of Team.

Most teams start with Starter for authenticated checks on a few critical endpoints, then move to Team when they need a login flow tested end to end or want 30-second detection. API monitors count toward the standard monitor limit; workflow steps draw on the monthly request allowance instead.

gRPC services can use the standard health protocol; see port and protocol monitoring. Full plan details are on the pricing page.