Response Assertions

A 200 OKdoesn't always mean things worked. Response assertions let you require a specific string in the response body — if it's missing, the run is treated as a failure even when the HTTP status looks fine. Available on Pro and Business.

How it works

Set an expected response string on the job. After a request returns a successful HTTP status, QuzenixCron checks whether the response body contains that exact substring:

Expected response:  "status":"ok"

Response body:      {"status":"ok","uptime":1234}   →  success ✓
Response body:      {"status":"degraded"}           →  failed ✗

When it's checked

The assertion only runs when the request itself succeeded (a 2xx/3xx status) and the body was readable. A failed HTTP status is already a failure, so the assertion doesn't need to run. A failed assertion counts as a failure for retries and notifications, just like any other failure.

Keep the string short and stable
Match on something that only appears on success and won't change run to run — a status field, a known marker, or a health keyword. Avoid timestamps or values that vary. The assertion is a plain substring match (not a regex), up to 500 characters.

Combine assertions with Retries & Failures and a notification channel so a soft failure pages you the same way a hard one does.

PreviousMissed-Run AlertsNext Heartbeat Monitors