Check types

CuliPulse has eight monitor types. This page covers what each one checks and its settings. Which ones run from a checkpoint is noted per type.

Website / HTTP

Requests a URL and decides health from the response. Runs from a checkpoint.

• URL and method (GET by default). Only GET, HEAD, POST, PUT, PATCH, DELETE, and OPTIONS are accepted.
• Expected status — a single code (200), a class (2xx), or a list (200, 301).
• Timeout — how long to wait before the request counts as failed.
• Request headers, and a request body with a content type.
• Secret fields — headers, a body, or bearer/basic auth can be marked secret; these are encrypted at rest and never shown back to you.
• Assertions — go beyond the status code: check that the response body contains text, that a JSON field at a path has a value, or that a response header matches.
• Response-time SLA — flag the monitor degraded (not down) when it responds slower than a threshold you set.
• Certificate expiry — warn (degraded) when the TLS certificate is close to expiring. This assertion runs on your own agent only.
• Domain-expiry add-on — optionally warn a set number of days before the URL’s domain registration lapses, without a separate monitor.

Port (TCP)

Opens a TCP connection to a host:port. Runs from a checkpoint.

• Target — host:port.
• Timeout.
• Banner check (optional) — send a small payload (up to 1 KB, as UTF-8 or hex) after connecting, and require the reply to contain a string or match a regular expression. With no banner set, a successful connection is enough to count as up.

Ping (ICMP)

Sends ICMP echo packets and reports whether the host answers, plus latency and loss. Runs from a checkpoint.

• Target — a host or IP (no http://).
• Packet count — 1 to 10 per check.
• Degraded thresholds (optional) — mark the monitor degraded above a packet-loss percentage or a round-trip-time in milliseconds. Set either to off to ignore it.

UDP service

Sends a datagram and checks for a reply. Runs from a checkpoint.

• Target — host:port.
• Payload / expect — same shape as the TCP banner check (send a UTF-8/hex payload, require the reply to contain or match). With no expect set, any reply counts as up.

Domain expiry

Looks up a domain’s registration once a day and warns before it expires. Checked by CuliPulse (no checkpoint).

• Domain — the bare domain (e.g. example.com). Its TLD must be supported by RDAP, or the monitor can’t be created.
• Warn days — how many days before expiry to start warning (1–3650, default 30).
• The interval is fixed at once a day regardless of what you pick elsewhere.

DNS records

Watches DNS records for drift. Checked by CuliPulse (no checkpoint).

• Hostname — the bare name to look up.
• Records — up to 20 rules, each with a type (A, AAAA, CNAME, MX, TXT, NS, CAA, SRV), a match mode (exact, contains, or present), and the expected value(s) (required unless the mode is present).
• Cross-check (optional) — compare answers across resolvers to catch inconsistent results.

Vendor status

Watches a supported third-party service’s official status feed, so their outage shows up as theirs, not yours. Checked by CuliPulse (no checkpoint), polled at most once a minute.

• Vendor — chosen from a supported list (not an arbitrary URL): GitHub, npm, Cloudflare, Discord, Vercel, Netlify, OpenAI, Anthropic, DigitalOcean, Datadog, Twilio, SendGrid, CircleCI, Zoom, Reddit, Atlassian, and AWS.
• Components — for most vendors you can narrow to specific components of their status page.
• AWS — picked by service and region (e.g. “S3 in eu-west-1”); you must choose at least one service/region pair. (AWS almost always has some event somewhere, so a watch-everything option isn’t offered.)

When it alerts

• Down — the vendor’s status page shows its overall status as a major or critical outage.
• Degraded — the vendor has posted an incident, or some of its components are having problems. If you picked specific components, an incident or outage on those components counts in full (a major one marks the monitor down).
• If the vendor’s status page can’t be reached, CuliPulse treats it as neither an outage nor an all-clear. The monitor keeps its current state and CuliPulse tries again a minute later. If the page stays unreadable for three checks in a row, the monitor shows unknown and you’re told it can’t be checked right now. The monitor’s last known status is still shown (for example “Major outage” if the vendor was down), labelled last known with how long ago it was read.
• “Alert me after N failed checks” works here too: the problem has to show on N checks in a row before you’re alerted.

Note

Need a vendor that isn’t listed? Vendor monitors only work with the supported list above — there’s no way to point one at an arbitrary status URL today.

Heartbeat

A dead-man’s-switch for your own scheduled jobs — nothing is probed; your job calls a URL to check in, and CuliPulse alerts you if a check-in is missed.

• Ping URL — a unique URL. Your job requests it on success; you can also signal the start of a run and a failure explicitly (separate paths).
• Grace period — how late a check-in may be before it counts as missed (defaults to the larger of 60 seconds or 20% of the interval).
• Max run duration (optional) — if you signal the start of a run, a run that takes longer than this marks the monitor degraded.

For rotating a heartbeat’s URL, see Managing monitors.