API monitoring: checks, assertions, and user journeys
Monitor an API for more than reachability: verify the response you expect, spot slowdowns, and alert the right people when the contract breaks.
Choose the right monitor
Use HTTP for a simple endpoint and status-code check. Use API when the request needs a method, body, headers, authentication, or a response assertion. Use Browser when success depends on several user-facing steps such as sign-in, navigation, or checkout. Use Heartbeat when the system calling out is the best proof that background work completed.
Configure a meaningful assertion
Start with one stable health or readiness endpoint. Expect a specific status code and, where useful, a small response-body value that proves the dependency is ready. Store credentials as secrets in the monitor configuration; never put production credentials in public documentation, status pages, or client-side code.
GET https://api.example.com/health
Expected status: 200
Expected body: {"ok":true}Assert on the response body
A status code only tells you the server answered. The keyword check asserts on what came back. Enter one assertion per line — every line must match, so several lines act as AND, not OR. Turn on "match as a regular expression" to treat each line as an RE2 pattern instead of literal text, which is how you assert on a value that changes: a version number, a timestamp, or one of several acceptable states. Turn on "keyword must be absent" to invert the whole check and fail when the text or pattern IS found, which is how you catch a stack trace or an error banner leaking onto a page. Two limits are worth knowing. RE2 has no lookahead, lookbehind or backreferences, so a pattern copied from a PCRE tool may be rejected when you save it; the error will say so. And only the first 1 MB of the response is searched — if a match sits past that, the check reports it was truncated rather than pretending the text is missing.
# Literal: every line must appear in the body
"status":"ok"
# Regular expression (RE2): every line must match
"status"\s*:\s*"(ok|healthy)"
"version":"4\.[0-9]+"When an endpoint is not enough
An API can return 200 while the customer-facing workflow still fails. Browser monitoring can validate the journey a person takes through the app. For queues, cron jobs, backups, and deploy pipelines, a scheduled heartbeat is often the more reliable signal because it confirms completion rather than only availability.
Respond to failures deliberately
Send incidents to the notification channels your team actually watches, then add triggers for the actions that are safe to automate. Keep noisy checks separate from customer-impacting checks so a single failure has a clear owner and notification path.
Related guides
The monitor-type guide covers all supported signals. The heartbeat guide contains copyable cron, worker, and GitHub Actions examples; notifications explains where incidents are delivered.