Concepts Checks HTTP

HTTP Check

The HTTP check sends an HTTP request to a URL and verifies the response. It's the most common check type — use it to confirm your web app, API, or any HTTP endpoint is responding correctly.

Source: HttpCheckExecutor.cs · HttpCheckData.cs

What it verifies

• The server responds within the timeout (default 5 seconds)
• The response status code matches what you expect (default: any 2xx)
• Optionally, one or more response rules pass (body content, JSONPath, XPath)
• Optionally, response latency stays under defined thresholds

Configuration

Field	Default	Description
url	—	The URL to request (required)
method	GET	HTTP method
headers	—	Key-value pairs added to the request
body	—	Request body (use with POST/PUT)
timeout	5000	Milliseconds before the request is aborted
followRedirects	true	Whether to follow HTTP redirects
expectedStatusCodes	—	Accepted status codes or classes; empty = any 2xx
responseRules	—	Ordered list of response body rules (see below)
degradedLatencyMs	—	Mark check DEGRADED if response time exceeds this (ms)
downLatencyMs	—	Mark check DOWN if response time exceeds this (ms)

Status codes

expectedStatusCodes accepts exact codes and class wildcards in the same list:

Format	Matches
"200"	Exactly HTTP 200
"2xx"	Any 200–299 response
"3xx"	Any 300–399 response
"4xx"	Any 400–499 response
"5xx"	Any 500–599 response

Legacy integer values (200, 301) are still accepted and treated identically to their string equivalents — existing configurations do not need to change.

When expectedStatusCodes is empty or omitted, any 2xx response is treated as UP.

Response rules

Response rules replace the older expectedBodyContains field and support richer assertions. Rules are evaluated in order; the first failing rule determines the check result.

Each rule has three fields:

Field	Required	Description
type	Yes	contains, not_contains, regex, json_path, or xml_path
value	Yes	The substring, regex, JSONPath expression, or XPath expression
expected	json_path / xml_path only	The value the expression must resolve to
degraded	No (default false)	When true, a failing rule marks the check DEGRADED instead of DOWN

Rule types

contains — the response body must include the given substring.

not_contains — the response body must not include the given substring.

regex — the response body must match the given regular expression.

json_path — evaluates a JSONPath expression (RFC 9535, via JsonPath.Net) against the response body and compares the result to expected. Supports full JSONPath including filter expressions.

xml_path — evaluates an XPath expression against the response body and compares the result to expected.

The degraded flag

When degraded: true, a failing rule signals that the service is degraded but not fully down. This is useful for non-critical assertions — for example, checking a secondary status field that indicates partial degradation.

Note: A rule with degraded: true that passes has no effect on the overall result. It only changes the outcome when it fails.

Latency thresholds

Latency is measured from when the request is sent to when response headers are received (not the full body download).

• If degradedLatencyMs is set and the response time exceeds it, the check is marked DEGRADED.
• If downLatencyMs is set and the response time exceeds it, the check is marked DOWN.
• Latency thresholds are evaluated after content rules.

Statuses

Status	When
UP	Response received, status code matches, all rules pass, latency within thresholds
DEGRADED	A rule with degraded: true fails, or response time exceeds degradedLatencyMs
DOWN	Wrong status code, a rule fails (without degraded), request timed out, or response time exceeds downLatencyMs
FAILURE	URL is empty or an unexpected error occurred during setup

Examples

Basic API health endpoint

{
  "url": "https://api.example.com/health",
  "method": "GET",
  "expectedStatusCodes": ["200"]
}

Accept any successful response (class wildcard)

{
  "url": "https://api.example.com/health",
  "expectedStatusCodes": ["2xx"]
}

Authenticated endpoint with body assertion

{
  "url": "https://api.example.com/internal/status",
  "method": "GET",
  "headers": { "Authorization": "Bearer my-token" },
  "expectedStatusCodes": ["200"],
  "responseRules": [
    { "type": "contains", "value": "\"status\":\"ok\"" }
  ]
}

POST endpoint

{
  "url": "https://api.example.com/ping",
  "method": "POST",
  "body": "{\"check\": true}",
  "headers": { "Content-Type": "application/json" },
  "expectedStatusCodes": ["200", "201"]
}

JSONPath rule — monitor Anthropic status via their Statuspage API

{
  "url": "https://status.anthropic.com/api/v2/summary.json",
  "responseRules": [
    {
      "type": "json_path",
      "value": "$.status.indicator",
      "expected": "none"
    }
  ]
}

The expression $.status.indicator extracts the top-level status indicator. If its value is not "none", the check fails.

JSONPath with filter — check a named component's status

{
  "url": "https://status.anthropic.com/api/v2/summary.json",
  "responseRules": [
    {
      "type": "json_path",
      "value": "$..components[?(@.name==\"Claude API\")].status",
      "expected": "operational"
    }
  ]
}

Latency thresholds — warn on slow responses, fail on very slow

{
  "url": "https://api.example.com/health",
  "degradedLatencyMs": 800,
  "downLatencyMs": 3000
}

Mixed rules — content check is non-critical, latency check is critical

{
  "url": "https://api.example.com/status",
  "expectedStatusCodes": ["2xx"],
  "responseRules": [
    { "type": "json_path", "value": "$.db", "expected": "ok" },
    { "type": "json_path", "value": "$.cache", "expected": "ok", "degraded": true }
  ],
  "degradedLatencyMs": 1000,
  "downLatencyMs": 5000
}

Here, a cache failure marks the check DEGRADED (not DOWN), while a db failure or a timeout above 5 s marks it DOWN.

Tips & best practices

• Prefer status code classes (2xx) over exact codes when your endpoint may return any success variant.
• Use degraded: true on secondary rules (cache status, secondary DB) to distinguish partial from full outages on your status page.
• Set both degradedLatencyMs and downLatencyMs together so operators see a warning before a hard failure.
• JSONPath filter expressions ([?(@.name=="...")]) are powerful for monitoring third-party status APIs that expose component-level data.
• Keep response rules focused — one rule per concern makes it easier to understand why a check failed.

Related

• Checks — common settings (schedule, thresholds, criticality)
• SSL Check — pair with HTTP to also monitor your certificate