← All features

Probe type · Free+

HTTP / HTTPS probe

The bread-and-butter check for any REST API, web app, or HTTPS service. Asserts more than just "200 OK" — covers headers, payload, status-code lists, latency, and body substrings in a single check.

Why you need it

An HTTP probe hits a URL on a schedule, applies a battery of assertions to the response, and reports Up, Degraded, or Down based on what it sees. Built specifically for the failures a TCP ping can't catch: the server is up, the socket is open, but the response payload is wrong or the latency has crept above your SLO.

Each check follows the same pipeline:

  1. DNS + TCP + TLS — resolve the host (IPv4 / IPv6), open the socket, complete the TLS handshake. Failures here are captured as Down with the underlying reason (NameResolutionFailure, certificate-mismatch, etc.) on the check result.
  2. HTTP request — sends the configured method (GET / POST / PUT / PATCH / DELETE / HEAD) with any custom headers + optional request body, follows redirects, and times the round-trip end-to-end.
  3. Assertions — checks the response against the operator's expected-status-code list (single value or semicolon-separated set: 200;204;301), optional body contains substring, and the latency threshold. Any failure flips the check to Down; latency over the threshold without other failures is Degraded.
  4. Persist + alert — every check writes a row to MonitorCheckResults with the status, latency, and the failure reason if any. A state transition fires alerts via every configured channel (email, Slack, Teams, SMS, webhook).

On Pro and Business, the same probe runs from multiple regions in parallel; quorum rules decide the public state from the per-region results. On Free and Starter the probe runs from one region (the tenant's primary).

Where it pays off

Use an HTTP probe when:

  • Public REST API — health endpoint (/healthz), versioned API root, a key business endpoint (the checkout, the login). Body-contains lets you assert that a deep-stack dependency is wired (e.g. "status":"ok" rather than just any 200).
  • Browser-rendered app — a single page returning 200 with the expected title in the HTML. Catches the "deployed but blank-page" regressions that a TCP probe misses.
  • Webhook receivers, OAuth endpoints, status APIs that don't accept arbitrary HEAD probes — the configurable method lets you send a POST with the exact payload the receiver expects.
  • Anything behind auth — the custom-headers field takes a Bearer token, an API key, or a tenant-routing header so authenticated endpoints are checked the way real clients call them.

Not the right choice when: the target speaks a non-HTTP protocol (use TCP / DNS / Ping / Database / WebSocket / gRPC instead), or when you need to assert TLS-cert-only details like signature algorithm or expiry days-left (use the SSL probe — it inspects the certificate without making an HTTP request).

Configuration parameters

Field Type Required Default Description
Name string Required Human-readable label for the probe. Shown in the dashboard, status page, and alert subject lines.
Target URL string (http:// or https://) Required Full URL including scheme. HTTPS is preferred for production targets. Internal hostnames are rejected at save time (SSRF guard).
Method GET, POST, PUT, PATCH, DELETE, HEAD Optional GET HTTP verb. POST / PUT / PATCH unlock the request-body field. HEAD is the cheapest option when the body doesn't matter.
Interval (seconds) integer Optional 60 Time between checks. Floor is plan-gated: 60 s on Free, 30 s on Starter+. Coarser intervals are always allowed.
Timeout (seconds) integer (1-120) Optional 30 Hard ceiling for the whole check (DNS + TCP + TLS + request + response). Exceeded → Down with TimedOut reason.
Expected status codes string (semicolon-separated) Optional any 2xx Codes that count as success: a single value (200) or a list (200;204;301). Blank accepts any 2xx.
Expected body contains string Optional Substring that must appear in the response body. Case-sensitive. Useful for asserting a deep-stack signal beyond status code.
Custom request headers JSON object Optional Map of header → value sent with every request. Used for Authorization, X-API-Key, tenant routing, content negotiation.
Request body string Optional (POST/PUT/PATCH only) Body sent with non-idempotent methods. Plain text — set Content-Type via custom headers if JSON / XML.
Latency threshold (ms) integer Optional Above this latency the probe reports Degraded even when the request succeeded. Leave blank to skip the latency tier and only flag Up / Down.
SLA target decimal (99.0-99.999) Optional Optional uptime SLO for the probe. Drives the SLA widget on the status page; doesn't affect alerts directly.
Paused boolean Optional false Master kill-switch. Paused probes don't poll and don't fire alerts. Doesn't delete the configuration or history.
Auto-email alerts boolean Optional true Per-probe switch on top of per-watcher toggles. When off, no email alerts fan out from this probe regardless of subscriptions.

Available on Free+. Already on StatusPulse? See the full config in Help →

Related

Try HTTP / HTTPS probe in StatusPulse

5 probes, 1 status page, forever. No credit card. US or EU host — you choose.