- Store credentials as a secretBelow the monitor form, use "Store a secret for headers" to save a token. Secrets are encrypted and never shown again.
- Choose the methodIn the HTTP(S) monitor form, pick the HTTP method. Non-GET methods are sent on every check.
- Add request headersUnder Advanced HTTP, choose "Add header", enter the name, and set the value source to Plain value or Stored secret.
- Add a body if neededFor POST, PUT or PATCH, enter the Request body (up to 64 KiB) and Content type.
- Set accepted status codesTick "Accept a custom status range" and enter the lowest and highest accepted status.
- Add response assertionsChoose "Add assertion" and pick Body contains text, Body does not contain text, Body matches RE2 pattern or JSON path.
Advanced HTTP checks let you monitor real API behavior, not just whether a URL responds. They are available on Starter and Team, inside the normal HTTP(S) monitor form under Advanced HTTP.
Methods and request bodies
Choose any HTTP method: GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS. The method is sent on every check, so make sure the endpoint has no unwanted side effects. A health endpoint or a read-only search is a good target; a "create order" endpoint is not.
For methods with a body, fill in Request body (up to 64 KiB) and Content type, for example application/json.
Headers and stored secrets
Choose Add header for each header. Set the value source to Plain value for harmless values such as Accept, or Stored secret for credentials such as an Authorization token.
To create a secret, use Store a secret for headers below the form: enter a Secret label and Secret value (for example Bearer eyJ…) and choose Store secret. Secrets are encrypted at rest and never displayed again, not even to you. Headers are only sent to the original origin: if the request is redirected to another origin, they are dropped so credentials do not leak.
Accepted status codes
By default 2xx and 3xx count as success. Tick Accept a custom status range and set Lowest accepted status and Highest accepted status, for example 200 to 204 for an API that must not redirect, or 401 to 401 to confirm an endpoint still requires authentication.
Response assertions
Assertions check the response body. Every assertion must pass for the check to pass.
- Body contains text and Body does not contain text: plain substring checks.
- Body matches RE2 pattern: a regular expression in RE2 syntax, for example
"version":"2\.\d+. - JSON path: a bounded JSONPath with the operator exists, equals or contains.
Paths support $.name, ["quoted name"] and [index]. Expected values are written as JSON, so text needs quotes. Examples:
| Path | Operator | Expected JSON value |
|---|---|---|
$.status | equals | "ok" |
$.checks.database.healthy | equals | true |
$.items[0].id | exists | (none) |
$["build-info"].region | contains | "eu" |
Plan notes
On Free the form shows these options with an upgrade hint, and the server refuses a configuration that uses them. Plain GET and HEAD checks with a status code and keyword stay available on every plan.
Frequently asked questions
Are my API tokens safe in a monitor?
Store them as secrets. Secrets are encrypted at rest, never displayed again, and dropped on cross-origin redirects.
Which regex syntax is supported?
RE2, the safe regular-expression syntax used by Go. It does not support backreferences or lookaround.
Can I chain several requests, such as log in and then call an API?
Yes, with an API workflow monitor on the Team plan. It runs up to 10 chained requests and passes values between them.
