Sign up

Check types

Every plan includes all 13 check types. See what each one verifies and which details come back with a result before you sign up.

Web
DNS and domain
Mail
Network
Host
Jobs

Plans set intervals and regions

Intervals go down to 10 seconds, depending on the plan. The web form offers 30 seconds and longer. Shorter intervals are set through MCP. The pricing page lists the shortest interval per plan.

The 11 regional check types use the regions included in the plan: 2 in Free, 3 in Pulse, and all 6 in Sentinel and above. Their regional policy is configurable and uses a quorum of 2 regions by default. The uptime monitoring page explains the regional rule.

agent and heartbeat carry no region and need no quorum, because the report comes from your host or your job.

Check URLs and security headers

http requests a URL and asserts on the result: an expected status code, a keyword the body must contain, or a regular expression against the body. It follows redirects up to 5 hops and validates every hop against SSRF targets before fetching it. An http monitor can also carry optional TLS certificate, security header, and DNS hygiene sub-checks, so one monitor covers what used to take four. Only the certificate sub-check needs https.

http_headers checks security headers as a separate monitor with its own record.

Check DNS, domains, and certificates

dns resolves a name and compares the answer set with what you expect. A DNS monitor can also cross-reference its answers against another monitor’s answer set. A divergence runs through the normal incident pipeline.

dns_hygiene checks SPF, DMARC, and CAA as configuration. These records decide whether your mail gets delivered and who may issue certificates for you.

domain watches the registration layer: NS and SOA consistency, DNSSEC, and WHOIS expiry. A domain inside its warning window, 14 days by default, turns degraded.

ssl_cert watches a certificate directly, independent of any http monitor. It checks validity, chain, expiry, and issuer, and it detects self-signed certificates.

Check mail servers

smtp and imap check the mail path that password resets and invoices depend on. From the probe regions in your plan, they verify that the server accepts connections and speaks its protocol.

Check reachability and the network path

ping checks whether the host is reachable at all. tcp checks whether a port accepts a connection, optionally with the TLS certificate served on that port. traceroute records the path, which is the evidence you need when a network in between is at fault, not your service.

Watch a host with the agent

agent binds a monitor to the host agent. It checks availability with a grace period, CPU, memory, and disk against thresholds, and named services with anti-flapping grace. A metric without fresh data produces no result instead of a false alarm, and an availability monitor marks a silent agent down.

One line installs the agent from the distribution point on Linux (x86_64, aarch64) and on macOS as a universal binary. On Linux it runs as a hardened systemd unit. It never collects command lines, environment variables, or usernames.

The agent updates itself with ed25519-signed releases. It verifies each release before the swap, fails closed, and needs no root helper. It uninstalls cleanly and deregisters from the cockpit.

Watch jobs with a heartbeat

heartbeat turns the direction around: your job calls Perstat instead of Perstat calling your service. That covers a cron run, a nightly backup, an importer, or anything else with no address to probe.

You get a secret URL, and the job requests it when it finishes. If that call stays out beyond the period plus the grace you set, the monitor goes down. A job that never ran is the failure ordinary monitoring cannot see, because nothing broke that anyone could reach.

Every heartbeat has a healthy endpoint and a failure endpoint. A job that ran and failed can call the failure endpoint, which marks the monitor down at the next evaluation instead of waiting out the schedule. Your script determines which endpoint it calls, so it can report any condition it can test, not only whether the job ran.

The monitor documentation has the exact URLs.

Regional results carry diagnostics

  • IPv4, IPv6, or both, per IP. Each reachability check runs on the address families you select, and on IPv4 when you select none. Results stay separated by family and IP. You decide whether a failure in one family counts as degraded or failed.
  • DNS time separated. Where applicable, dns_ms is reported apart from total latency, so a slow resolver does not look like a slow app.
  • Cause attribution. Where a supported probe check emits attribution, it names the layer: your app or your DNS, the network, or our resolver or our own node. Unknown remains valid while the cause is not determined, and not every outcome carries a cause layer.

Start monitoring free or take the product tour. The tour needs no signup.