Monitoring

API monitor

Call an endpoint with your own method, headers and body, and check the answer.

What it checks

Like a Website, but you choose the HTTP method, request headers and body. The monitor is up when the status code is in your range and every rule passes, including checks on JSON fields.

When to use it

For health endpoints, JSON APIs, webhooks that need a POST, or anything behind an API key or token.

Create it

Open /app and click New monitor.
Under What to monitor choose API.
Under Details enter a Name and the URL, for example https://api.example.com/health.
Choose the Method: GET, POST, PUT, PATCH, DELETE or HEAD. For POST, PUT, PATCH or DELETE you can add a Body (optional), up to 10,000 characters.
Open Advanced to add Headers (one per line, Name: value), for example Authorization: Bearer your_token or Content-Type: application/json.
Under Rules set the status range and JSON checks.
Under Schedule pick Check every and, if you want, Alert after (failed checks in a row before an alert).
Under Check from choose the regions that run the check.
Under Alerts choose where alerts go (Send alerts to). See Alerts.
Click Create monitor. The first check runs right away.

Check interval

Under Schedule, Check every offers 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour and 1 day. The shortest is 1 minute (on the Free plan 5 minutes). Intervals your plan does not allow are greyed out.

Request settings

Setting	How it works
Method	GET, POST, PUT, PATCH, DELETE or HEAD. A HEAD response has no body, so content and JSON checks cannot match it.
Body (optional)	Sent as is. Up to 10,000 characters.
Headers	Up to 20 headers, one per line as `Name: value`. Secret values (such as Authorization or tokens) are shown as `********` after saving and are kept unless you type a new value.
Basic auth user and password	Sent as an Authorization header.
Timeout, Retries on failure	1 to 60 seconds, and 0 to 3 retries.
Ignore TLS certificate errors	For self-signed endpoints.

Rules: what counts as up

These are in the Rules card. A monitor is down unless the response passes every rule.

Setting	How it works
Up when the status code is between	Two numbers, from 100 to 599. The default is 200 to 399. Redirects are not followed, so a 301 or 302 must be inside the range to count as up.
Degraded when slower than (ms, optional)	50 to 120000 ms. A healthy but slow answer shows as Degraded, not down.
Page must contain (optional)	Text that must appear in the response body, up to 200 characters. Upper and lower case count as different.
Page must not contain (optional)	The monitor is down when this text appears, for example `Fatal error`. Case sensitive.
JSON checks (optional)	Up to 5 checks on fields of a JSON response. See below.
Response header checks (optional)	Up to 5 checks on response headers. See below.

JSON checks

Each check has a path, an operator and a value. Write the path with dots and brackets, for example data.status or items[0].ok. The response must be JSON; if it is not, the monitor is down. Values are compared as text.

Operator	Passes when
equals	the field is exactly the value, for example `status` equals `ok`
does not equal	the field is missing or different
contains	a text field includes the value, or a list has an item equal to it
is greater than / is less than	the field is a number above or below the value (the value must be a number)
exists	the field is present and not null (no value needed)

Examples: status equals ok, data.items[0].price is greater than 0, error exists (use does not equal or the rule below to fail on it).

Response header checks

Each check has a header name (letters, digits and dashes, up to 60), an operator and, for most operators, a value (up to 200 characters). Names and values ignore upper and lower case.

Operator	Passes when
exists	the header is present
does not exist	the header is absent
equals / does not equal	the header value is / is not exactly the value
contains / does not contain	the header value includes / does not include the text
starts with	the header value begins with the text

Example

content-type contains application/json
strict-transport-security exists
x-powered-by does not exist
cache-control starts with no-store

Plan. Content, JSON and header rules are the plan feature Keyword and JSON rules. It is on in the standard plans. If your plan does not include it, saving a monitor with these rules is refused with a message that says so.

Example: a health endpoint

The endpoint answers {"status":"ok","db":{"connected":true}}. Add two JSON checks: status equals ok and db.connected equals true. If either is wrong the monitor goes down, even with a 200 status.

What the monitor page shows

The same as a website monitor: a Response section (status code, final URL, server, content type, size, Cache-Control, HSTS or the error) and a Timing breakdown (DNS lookup, TCP connect, TLS handshake, time to first byte, download). Request headers and bodies are never shown.

Alerts

You are alerted when the monitor goes down and when it recovers, through the channels you pick. Alert after sets how many failed checks in a row are needed (1 to 5). Quiet hours, reminders and escalation work as described in Alerts.

Common problems

401 or 403. Add the right Authorization header under Advanced.
JSON check always fails. The response must be JSON, and the path must match exactly, for example data.items[0].id. Numbers and booleans are compared as text, so use true or 42.
Rules not saved. Your plan may not include Keyword and JSON rules.