Skip to content

HTTP monitor

Monitor any URL for availability, response time, status codes, and body content.

Last updated March 22, 2025

The HTTP monitor is the most common check type. It sends an HTTP request to a URL on your configured interval and records availability, response time, and status code.

Overview

Every HTTP monitor check records:

  • Whether the endpoint returned a successful status code (2xx by default).
  • Total response time in milliseconds (DNS + TCP + TTFB + body).
  • Response body and headers (stored for 7 days for debugging).

Configuration options

  • URL — The full URL including protocol.
  • Method — GET, POST, PUT, DELETE, HEAD, OPTIONS.
  • Request headers — e.g. Authorization: Bearer TOKEN.
  • Request body — JSON or raw string for POST/PUT requests.
  • Expected status — Default 2xx; override to any code range.
  • Timeout — Mark as down if no response within N seconds (default: 30s).
  • Follow redirects — Enabled by default; disable to assert on redirect responses.

Assertions and keyword checks

Beyond status codes, you can assert on response body content. A keyword check fails the monitor if the response body does not contain — or does contain — a specific string.

text
Keyword:  "status":"operational"
Match:    must contain
Result:   DOWN if the API no longer returns that JSON field

Case sensitivity

Keyword matching is case-sensitive. Use lowercase strings for JSON values to avoid false positives.

Multi-region checks

Paid plans run checks from multiple geographic regions simultaneously. Each region runs the check independently and writes its own result, so you can see exactly which locations succeeded or failed. Auto-incidents open after three consecutive down results, which makes single-region blips unlikely to page you on their own even though every individual result still updates the monitor's last status.

See Multi-region checks for the full list of available regions, plan limits, and tuning guidance.