Skip to main content

Response settings

Response settings decide whether a response should count as healthy after the request has completed.

Status codes​

Status code rules support exact values and simple wildcard groups.

Examples:

  • 2* accepts any status code from 200 to 299;
  • 200, 204 accepts only 200 and 204;
  • 401 can be valid for a protected endpoint if that is what you expect.

Keep this rule broad for normal websites and stricter for APIs. For example, a marketing page usually wants 2*, while a health endpoint often wants exactly 200.

If a site returns 403, 429, 405 or another intentional non-200 status, read Allowlisting and HTTP status codes before deciding whether to accept that status as healthy.

Optional text checks​

Text checks are optional. Use them only when a page or API response must include or must not include a specific phrase.

The "must appear" rule fails the check when the text is missing. The "must not appear" rule fails the check when the text is found.

Good examples are stable phrases such as a product name, status: ok, or error phrases that should never appear, such as maintenance, database error or rate limited.

Text rules are useful when a server returns 200 OK for an error page. In that case the HTTP status alone is not enough to prove that the service is healthy.

Optional response header checks​

Header checks are optional. Use them when a response header proves that the endpoint is serving the right kind of response.

Common examples:

  • cache-control contains max-age;
  • content-type contains application/json;
  • x-powered-by does not contain a framework name you want hidden.

Supported conditions:

  • contains;
  • equals;
  • does not contain;
  • matches pattern.

Wildcard matching with * can be used for flexible patterns. For example, max-age=* can match changing cache lifetimes without making the monitor noisy.

Optional JSON body checks​

JSON body checks are optional and are intended for API endpoints that return JSON. Normal HTML pages usually do not need them.

Examples:

  • status equals ok;
  • data.items.0.id exists or matches a value;
  • data.*.state can inspect multiple nested entries.

If any required assertion fails, Uptimus marks the check as failed.

Use body assertions for API health checks where a response can be technically reachable but still wrong. Keep assertions focused on stable fields, such as status, healthy, version or a known tenant identifier.

Evaluation order​

Uptimus evaluates response rules in a predictable order:

  1. HTTP status code.
  2. Required and forbidden text.
  3. Final redirect URL, when configured.
  4. Response header assertions.
  5. JSON body assertions.

The first failed rule is enough to mark the check as failed, but check details can include multiple assertion failures when the response can be inspected.