Assertions
A 200 OK doesn’t mean the response is correct. Assertions let you verify the shape of what came back — header values, body substrings, JSON path equalities — and downgrade a run to degraded or down when the response drifts.
Assertions live on the Assertions section of the add-endpoint form, and on the matching panel of the endpoint Settings tab.
The assertion model
Each rule is a four-tuple:
| Property | Meaning |
|---|---|
kind | What you’re asserting on — body, header, json, latency, or ssl. |
operator | How to compare. Allowed operators differ per kind — see below. |
target | Which thing to inspect. Header name for header, dotted JSON path for json. Unused for body, latency, ssl. |
value | The value to compare against. Numeric for latency/ssl; string for the rest. |
severity | down (open an incident) or degraded (visible drift, no page). |
Up to 10 assertions per endpoint.
Allowed operators by kind
| Kind | Operators | Value type | Notes |
|---|---|---|---|
latency | lt · lte · gt · gte · eq | ms | Overrides the Monitoring-tab latencyThreshold when set. |
body | contains · not_contains · equals | string | Substring matching only — no regex. |
header | exists · not_exists · equals · contains | string | target is the header name; matching is case-insensitive. |
json | exists · not_exists · eq · neq · lt · lte · gt · gte · contains | string/number | target is a dotted path (user.email, data.0.id); no wildcards or filters. |
ssl | lt · lte · gt · gte · eq | days | Overrides the SSL warning window when set. |
Body matching is substring only — there’s no regex engine in the cloud evaluator. For richer pattern matching, return JSON and use a json assertion against a stable path.
Status code is not an assertion
The expected response status is a first-class field on the check, not an assertion. Set it via the Status code chips on the General section (default [200]). The status evaluator runs before assertions and short-circuits the run to down when the code doesn’t match — assertions don’t even get a chance to fire.
Severity — down vs degraded
When a rule fails, the run takes that rule’s severity. If multiple rules fail, the worst severity wins (down beats degraded).
When the status evaluator already produced down (network error, wrong status code, port refused), assertions are skipped entirely — once the request itself failed, asserting on its response doesn’t make sense.
Quick-add presets
The Assertions section has four preset chips that append a draft assertion in one click:
- Latency < 1s —
latency lt 1000(severity: degraded). - Body contains “ok” —
body contains "ok"(severity: down). - Content-Type is JSON —
header contains "application/json"onContent-Type(severity: down). - JSON
$.status == "ok"—json eq "ok"on pathstatus(severity: down).
These are starting points — adjust the operator, value, severity, or kind once added.
Testing live with “Test now”
The Assertions panel has a Test now button that fires a one-shot probe against your configured URL. It runs the same status evaluator and assertion engine as a real check but writes nothing to your check history. The result panel shows:
- The base status —
healthy,degraded, ordown— with the reason. - The probe details — status code, latency, content type, body size, SSL days remaining.
- A per-assertion pass/fail breakdown including the actual value the rule saw.
Use it while drafting assertions to confirm your JSON path resolves, your substring is present, or your latency budget is realistic — before committing the endpoint.
Test now is HTTP-only. The button is hidden for TCP / port checks since they have no response body or headers to assert on.
What’s next
- SSL & certificates — when to use an
sslassertion vs the Monitoring-tab warning window. - HTTP checks — full list of fields that govern the request itself.
- Troubleshooting — common gotchas when an assertion isn’t matching what you expect.