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 type | For what | Target |
|---|---|---|
| Website (HTTP/HTTPS) | websites, APIs, health endpoints | a URL, for example https://example.com |
| TCP port | mail servers, databases, other services | host 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: trueNote
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