All monitor types
Basic monitoring

HTTP(S) monitoring

Status, latency, redirects, response headers and body/JSON assertions — over HTTP or HTTPS.

Every HTTP(S) monitor runs on the same spine as the rest of PulseTrace — probed from each region you pick, scored on every check, and streamed into one timeline where incidents open on their own, anomalies surface without a threshold to guess, and reports are generated for you. Point it at a target, choose an interval, and it's watched.

What each check verifies

  • Response status code and total latency
  • Redirect handling — follow up to 10 hops, or report the redirect itself
  • Response header, body-content and JSON-field assertions
  • Pre-request scripts and on-demand executions (HTTP family only)

The panel on the right is the real create-monitor screen — it fills itself in with a HTTP(S) example, exactly what you'd type.

When to use it

The default for anything with a URL: web pages, REST and GraphQL APIs, health endpoints, webhooks you expose. Use it wherever 'does it answer, how fast, and is the answer right' is the question — assertions on status, headers, body and JSON make it an API monitor, not just a ping.

What an alert looks like

Checkout API is DOWN — HTTP 503 from us-east, eu-west (2 of 3 regions); assertion `status == 200` failed for 2 consecutive checks.

Questions about HTTP(S) monitoring

Can it follow redirects?
Yes — follow up to 10 hops and assert on the final response, or report the redirect itself so a new 301 becomes a change event.
Can I send a body and headers?
Yes — any method, custom headers, a request body, and a credential from the vault; pre-request scripts can compute signatures and timestamps.
Does it capture the response when a check fails?
Yes — the failing execution keeps status, headers, timing and the body excerpt the assertion looked at, so the incident shows what the API actually returned.