Check types and extra checks

Updated July 21, 2026 · 5 min read

When creating a monitor you pick one of two check types. For websites and APIs, optional extra checks let you verify more than plain availability.

Two check types

You set the check type when creating a monitor, and it is fixed afterwards. The options are:

Check typeFor whatTarget
Website (HTTP/HTTPS)websites, APIs, health endpointsa URL, for example https://example.com
TCP portmail servers, databases, other serviceshost and port, for example mail.example.com:25

Extra checks for HTTP

For the Website (HTTP/HTTPS) check type, advanced options reveal further checks. They are all optional and can be combined freely.

  • Expected status codes: comma separated, for example 200, 301. Left empty, all 2xx responses count as reachable.
  • Keyword: checks whether a given text appears on the page, or does not appear (keyword mode).
  • JSON field: checks a field in a JSON response against an expected value.
  • Header: checks a response header against an expected value.

Checking a JSON field

For health endpoints that return JSON, you give the path to the field and the expected value. The path uses a simple dot notation with array indices. Wildcards or filters are deliberately not supported.

JSON path: $.status Expected value: ok # nested deeper JSON path: data.items[0].ok Expected value: true

Note

Both fields of a pair must be filled for the check to apply. If the value differs, the monitor counts as down, even if the status code is 200.

Checking a header

Just like the JSON field, you check a response header, for example content-type against application/json. The header name is matched case-insensitively, the value compared exactly.

Frequently asked questions

Can I change the check type later?

No. HTTP and TCP work differently under the hood, so the check type is fixed after creating. If in doubt, create a new monitor.

Ready? Create your first monitor, three are free forever.

Monitor for free