Advanced Expected Conditions

Last updated: 2026-04-14

Advanced Expected Conditions let you describe what a successful (UP) response looks like.

• If your conditions match, the check is UP.
• If they don’t match, the check is DOWN.

If you leave Advanced Expected Conditions empty, the default behavior applies (for HTTP/API monitors this is typically 2xx/3xx = UP).

ALL (AND) vs ANY (OR)

You can combine multiple conditions:

• ALL (AND): every condition must match for the monitor to be UP.
• ANY (OR): at least one condition must match for the monitor to be UP.

Tip: When you want a strict health check (status code + JSONPath + latency), use ALL (AND).

Suggested conditions from URL preview

In the Add and Edit Monitor forms, the dashboard can probe the URL you enter and suggest validation conditions automatically.

If you are working through the full Add Monitor flow, see Setting Up Your First Monitor alongside this guide.

• For Site and API monitors, a valid URL preview can show status code, response time, and content type.
• If the response looks like JSON, the validation section can offer clickable JSONPath suggestions such as $.status.
• When editing a monitor, changing the Site URL refreshes these suggestions automatically after a short pause while you type, so you do not need to click away first.

Use the suggestions as a starting point, then tighten them with AND/OR logic as needed.

Condition types

Status Code

Validates the HTTP response status code.

Examples:

• equals 200
• range 200-299

Body Contains

Checks the response body as text.

Common operators:

• contains (default)
• not_contains
• matches (regex)
• equals (exact match)

JSONPath

Extracts values from a JSON response body and compares them.

This is the most reliable way to validate structured API responses.

Guide: Advanced API Monitoring with JSONPath

Header

Validates HTTP response headers.

Use this when you need to assert a header value (for example, a specific cache header, content type, or version header).

Response Time

Validates how long the request took (in milliseconds).

Important: response time conditions are evaluated the same way as other conditions — they describe when the monitor is UP.

Examples:

• To mark the monitor DOWN when response time exceeds 45s, configure: Response Time lt 45000.
• To require a minimum response time (rare): Response Time gte 100.

Recommended patterns

“Healthy JSON response + acceptable latency” (strict)

Use ALL (AND):

• Status Code range 200-299
• JSONPath $.status equals ok
• Response Time lt 45000

“Either of two acceptable success states” (flexible)

Use ANY (OR):

• JSONPath $.status equals ok
• JSONPath $.status equals degraded

Troubleshooting

• If a monitor is DOWN while the service looks healthy, double-check that your conditions describe success (UP), not failure.

  • Example: JSONPath $.status not_contains ok will only be UP when the status is not ok.
  • Example: Response Time gt 45000 will only be UP when latency is greater than 45s.

• If you’re validating JSON, prefer JSONPath over Body Contains.

• If your conditions are too strict, consider switching from ALL (AND) to ANY (OR).

• If URL suggestions do not appear, confirm the URL is publicly reachable and returns valid JSON for JSONPath suggestions.

• If you changed the Site URL while editing a monitor, wait a moment after typing. The preview and suggestions refresh after a short debounce rather than on every keystroke.

Related Docs

• Setting Up Your First Monitor
• Monitor Types
• Monitoring Configuration Examples
• Advanced API Monitoring with JSONPath