Probes

Why you need it

A probe polls one of your endpoints on a schedule, applies the assertions you configured, and writes a result that drives everything else: the public status page, the SLA widgets, the email / Slack / Teams / SMS alerts, the latency charts, the PDF reports, the anomaly detector. Eleven probe types ship today, each built for a specific protocol — none of them rely on "did the socket open" as the only signal:

• HTTP / HTTPS — method + headers + body + expected status-code lists + body-contains assertions + latency thresholds.
• SSL / TLS certificate — days-to-expiry with two operator-set thresholds, plus full chain inspection (issuer, SANs, signature algorithm, TLS version).
• Ping (ICMP) — true ICMP echo via a dedicated dual-stack sidecar, IPv4 + IPv6, loss-percentage and RTT thresholds.
• TCP / port — connect with timing, optional TLS wrap (SMTPS / IMAPS / LDAPS), optional banner-grab assertion.
• DNS record — seven record types (A / AAAA / CNAME / MX / TXT / NS / CAA) with ExactMatch / Contains / AnyMatch modes and an optional resolver override for propagation testing.
• Domain expiration — RDAP-first with WHOIS fallback, surfaces registrar / name servers / EPP status / DNSSEC, and fires Down on registrar OR nameserver-set drift.
• Heartbeat (cron) — passive probe; your job pings a unique URL, absence flips it Down. Simple interval or full cron expression, frequency-anomaly detection on the rolling window.
• Email round-trip — three depth modes from SMTP-submission-only to full SPF/DKIM/DMARC verdict parsing.
• Database — PostgreSQL, MySQL, SQL Server, Redis, with auth + ping + custom SELECT assertions, encrypted credentials.
• WebSocket — connect + 101, subprotocol assertion, RFC 8441 (HTTP/2) support, optional RTT echo.
• gRPC Health — overall Check, per-service Check, Watch first-frame, mTLS with encrypted client certs.

Every probe shares the same plumbing — status pill (Up / Degraded / Down / Paused / Unknown), latency history, SLA target, alert fan-out, report inclusion — so adding a new check type to your dashboard is one modal away, not a separate sub-product.

Where it pays off

Probes are the foundation of the product — if you're using StatusPulse at all you're using probes. The interesting question is which probe type to reach for, and the answer is usually "more than one for the same target":

• Public web app or REST API — HTTP probe on the health endpoint, plus an SSL probe on the same host so the "certificate expired on a Sunday" failure mode is caught a fortnight early, plus a Domain expiration probe so the registrar lapse is caught a month early.
• Backend infrastructure — TCP probe for the port, Database probe for the engine itself (real SELECT 1 over authenticated connection), DNS probe to catch a misconfigured resolver chain.
• Async / batch / cron jobs — Heartbeat probe; your job ships a beat and absence flips Down. Pairs with the anomaly detector to catch a job that's running too often or flapping in cadence.
• Real-time stacks — WebSocket probe with subprotocol assertion for the upgrade path, gRPC Health probe for the service-level health contract.

Not the right choice when: you want browser-rendered, JavaScript-heavy end-to-end synthetic checks (StatusPulse probes are protocol-level, not headless-browser scenarios). For "did my SPA hydrate" or "did checkout complete in a real Chrome", a synthetic-browser tool sits alongside StatusPulse rather than being replaced by it.

Configuration parameters

Related

• HTTP / HTTPS probe
• SSL / TLS certificate probe
• Ping (ICMP) probe
• TCP / port probe
• DNS record probe
• Domain expiration probe
• Heartbeat (cron) probe
• Email round-trip probe
• Database probe
• WebSocket probe
• gRPC Health probe
• Multi-region probes
• Anomaly detection