By default, a check is considered healthy as long as a response arrives — even a 500 Internal Server Error counts as “up”. Assertions let you be more specific about what a good response looks like.
A check fails if any assertion fails. All assertions must pass.
Types of assertions
Status code
The most common assertion. Marks the check as down if the response code isn’t what you expect.
Examples of what you can set up in the dashboard:
- Status code equals 200
- Status code is one of 200, 201, 204
- Status code is less than 400 (catches all error codes)
Response time
Marks the check as down if the response is too slow. Useful for catching degradation before it becomes a full outage.
- Response time less than 2000ms (2 seconds)
- Response time less than 500ms for latency-sensitive services
Body content
Checks the raw response body text. Useful for confirming your service is actually serving content, not just returning an empty 200.
- Body contains
"status":"ok" - Body does not contain
error - Body equals
pong(for simple ping endpoints)
Header
Checks the value of a specific response header.
content-typecontainsapplication/jsoncache-controlequalsno-cachex-maintenance-modedoes not exist
Common setups
Basic uptime check — just add a status code equals 200 assertion. Simple and covers most cases.
API health check — combine status code equals 200 + body contains your expected health token + response time under 1 second.
No silent failures — add a body does-not-contain assertion for words like error, exception, or Internal Server Error to catch apps that return 200 with an error page.
Without any assertions, Watchplane only checks that a response arrives. Always add at least a status code assertion for meaningful monitoring.