HTTP(S) check

What it verifies

An HTTP(S) monitor requests the URL at its interval from each of its regions. It checks the status code and, if set, a keyword or a regular expression in the body, and it records the response time. Optional sub-checks for the certificate, the security headers, and DNS hygiene run in the same monitor, so one failing host opens one incident rather than four.

Use it when

• A service has an HTTP endpoint that answers when the service is healthy: a health path, a home page, or an API route.
• The answer needs a content check, not only a reachability check: a status code, a string in the body, or a pattern.
• The certificate, the header posture, and the domain’s SPF, DMARC, and CAA records should be checked in the same monitor instead of in 3 extra monitors.

It runs no browser journey, does not log in, and follows at most 5 redirects. For a port without HTTP, use the TCP check. For a certificate that deserves its own incident, use the TLS certificate check.

Swipe sideways to inspect the product view.

app.perstat.io

Configuration

Target. A full URL including the scheme (https:// or http://). The probe resolves and validates the URL and every redirect hop before fetching. It refuses loopback, private, link-local, and cloud metadata addresses, so the monitor cannot be pointed into an internal network.

TLS certificate

On an https URL, the same monitor judges the certificate it was served: the handshake, the chain, the issuer, and the subject. The form switches this sub-check on for every https URL.

Security headers

The probe sends a second request and checks its response for the selected headers. Only their presence counts. A missing header is a posture finding, not an outage, so the default severity is degraded.

DNS hygiene

The probe reads SPF, DMARC, and CAA of the domain as configuration. These records decide whether the domain’s mail is delivered and who may issue certificates for it. The finding appears with the result and never changes the monitor state.

How a check runs

1. When a check is due, each region compiles the regex first. An invalid regex ends the check as an error. Every check times out after 10 s.
2. The node resolves the host through its own resolver and validates every address of the selected family against the blocked ranges. Each address then gets its own request, with the connection pinned to that address.
3. The probe follows redirects itself, at most 5 hops. It resolves and validates every hop again before it fetches it.
4. The probe judges the status code first, then the keyword and the regex. It reads the body only when one of them is set, and all assertions combine with AND.
5. Only a passing https check with the TLS certificate sub-check on runs the certificate policy, once per check. A passing or degraded check adds the header grade and the DNS hygiene finding as separate sub-results.
6. The region sends its result to the control plane. The alert policy decides whether a failed result opens an incident once the quorum agrees. A degraded result stays out of the incident evaluation.

Swipe sideways to inspect the product view.

app.perstat.io

What a result contains

Status code

The final status after redirects, judged against expected_status.

Response time

Time to the answer, including the body when it is read, per region and per address (latency_ms).

Detail line

One line that says what happened, for example HTTP 200, keyword not found, or regex did not match. It also names an unexpected status or the transport error.

Cause layer

Whether a failure sat with the target’s DNS (name not found) or, after a successful lookup, with the target itself. Every other cause is reported as unknown.

Certificate

Common name and alternative names, issuer, validity dates with days left, and trust status.

Security headers

Which of the requested headers were present and which were missing.

DNS hygiene

The SPF, DMARC, and CAA findings, for example a DMARC policy of none or a missing CAA record.

Region, family, address

Every result carries the region that measured it, and one sub-result per IP family and per address.

States and severity

• okThe status matches and every assertion holds. A certificate inside its warning window keeps this state.
• degradedA security header is missing at the default severity, or one IP family fails while the other answers.
• downThe request fails, times out, or is blocked, or the status or an assertion misses. A failing certificate policy (expired, rejected handshake, issuer or subject mismatch) and a missing header at failed severity count too.
• errorThe configuration cannot run, for example because of an invalid regex. It counts as an outage with severity critical.

Confirmed by quorum: by default, 2 regions must report the failure before an incident opens. The organization default asks for 2 regions and 2 consecutive checks. A monitor can carry its own rule with count or percent, consecutive checks, and a minimum duration.

Plans and limits

Shortest interval

300 s on Free, 60 s on Pulse, 30 s on Sentinel, 15 s on Command, and 10 s on Enterprise. The web form offers 30 s, 1 min, 5 min, 15 min, and 1 h. The 15 s and 10 s floors are reachable only through MCP.

Regions

2 of 6 on Free, 3 of 6 on Pulse, and all 6 from Sentinel.

Monitors

10 on Free, 50 on Pulse, 150 on Sentinel, 500 on Command, and a custom quota on Enterprise. Eleven probe types share this quota, while host agents and heartbeats have their own. A pack of 50 more monitors costs €39.

Compare every plan limit

From the pipeline or an agent

The same config works in the deploy step, in an MCP client such as Claude Code, and in the form above. create_monitor needs an organization-wide API key. If you omit regions, the plan picks its default.

{
  "name": "Order API",
  "type": "http",
  "interval_seconds": 60,
  "config": {
    "url": "https://orders.example.com/health",
    "expected_status": 200,
    "keyword": "ok",
    "tls_cert": { "enabled": true, "warn_days": 21 },
    "security_headers": {
      "enabled": true,
      "headers": ["strict-transport-security", "content-security-policy"],
      "missing_severity": "degraded"
    },
    "dns_hygiene": { "enabled": true }
  }
}

Every interface, with its boundary

Limits

• The probe runs no browser journey, executes no JavaScript, and follows no login flow. It sends no request body and no cookies.
• Method and request headers are set over the API or MCP, not in the form.
• The probe follows at most 5 redirect hops, and a longer chain fails the check.
• The security header grade checks presence, not values.
• The probe refuses targets on private, loopback, link-local, and cloud metadata addresses.
• Not every region probes IPv6, so selecting ipv6 restricts the usable regions.

Related check types

• Security headers checkPresence of 5 security headers on a URL, as its own monitor with its own record.
• TLS certificate checkExpiry, issuer, and subject of a certificate by direct TLS handshake, with an advisory ahead of expiry.
• TCP port checkWhether a port accepts a connection, optionally with the certificate served on it.
• DNS hygiene checkSPF, DMARC with its policy, and CAA of a domain, graded as posture and never as an outage.

All check types