HTTP Content Check Reference

All parameters, thresholds, and configuration options for the HTTP content check in octoja.

Written By Erdinc Akay

Last updated About 2 months ago

The HTTP Content Check monitors web endpoints for expected status codes, response content, and response time.

Configuration fields

FieldTypeRequiredDefaultDescription
Endpoints to monitorListYes—One or more endpoints to monitor
— URLStringYes—HTTP(S) endpoint URL
— HTTP MethodStringNoGETHTTP method. One of: GET, POST, HEAD. With HEAD, the response body is not read — Expected content substring, Forbidden content substring, response size, and the content-match metrics are not evaluated (shown as N/A)
— Custom headersKey-valueNo—Custom HTTP headers
— Request bodyStringNo—Request body. Only sent when Method is POST
— Expected status codeIntegerNo200HTTP status code indicating success
— Expected content substringStringNo—Text that must appear in the response body
— Forbidden content substringStringNo—Text that must NOT appear in the response body
— Warning response time (ms)msNo5000Response time that triggers a warning
— Critical response time (ms)msNo15000Response time that triggers a critical result
Timeout (ms)msNo30000Request timeout in milliseconds (valid range: 1000–120000)

The check interval is configured on the check assignment, not on the check itself. Valid values: 5–1440 minutes; the default for the HTTP Content Check is 10 minutes.

Collected metrics

  • HTTP status code
  • Response time (ms)
  • Response size (bytes)
  • Content match (found / not found)
  • Forbidden content (found / not found)

Platform support

PlatformSupported
WindowsYes
LinuxYes
macOSYes

Notes

  • A status-code mismatch, missing expected content, present forbidden content, or any request error each produce a Critical result. Only a response time between the warning and critical thresholds produces a Warning.
  • Redirects are followed automatically (up to 5), so the expected status code is compared against the final response after redirects.
  • Content matching is case-sensitive. Use exact strings that appear in the response body.
  • If both expected and forbidden content are configured, the check succeeds only when the expected text is present AND the forbidden text is absent.
  • For endpoints that require authentication, include the credentials in the custom headers (e.g. Authorization: Bearer <token>).
  • This check does not verify SSL certificates. For SSL certificate expiration monitoring, use the SSL/HTTP Check.

See also: Configure an HTTP Content Check