Skip to content

Monitor types

A monitor is one configured check. Its type decides what is probed and what shape its config takes; everything else — name, interval, locations, tags, service — is common to all of them.

WireWatch registers 7 monitor types.

The type is fixed when the monitor is created and cannot be changed afterwards: the config of one type is not the config of another, so switching would silently discard it. Create a new monitor instead.

Six of the seven are active probes: WireWatch dials your target on a schedule from the locations you choose, so each one requires an interval, a timeout and at least one probe location. heartbeat is the exception — it is inverted, and has none of the three.

Issues an HTTP request and judges the response.

  • method — one of GET, POST, PUT, PATCH, DELETE, HEAD.
  • url — an absolute http(s) URL. Any other scheme is rejected.
  • headers — optional request headers.
  • body — optional request body.
  • followRedirects — defaults to true.

The only type with monitor-level assertions: status code, response time, body content and response headers — see Assertions for which ones the probe evaluates today. A monitor with no status_code assertion passes only when the request completes with a status of 200–399; a status_code assertion replaces that default.

The target is checked for reachability when you save it, and again at probe time: a private, loopback, link-local or cloud-metadata address is refused, and a redirect into one of those ranges is not followed.

Opens a TCP connection to host:port and closes it.

  • host — a hostname or address.
  • port — 1–65535.

The handshake is the check. There is nothing to assert beyond it, so this type takes no assertions. Use it for anything that speaks a protocol WireWatch does not: a database port, a message broker, a mail server.

Completes a TLS handshake and reads the certificate.

  • host — a hostname or address.
  • port — defaults to 443.
  • warn_days — 1–365.

Two separate signals, and confusing them is the usual mistake:

  • the handshake is the up/down verdict — an expired, untrusted or mismatched certificate fails the check and can open an incident;
  • warn_days is a dashboard threshold only. A certificate expiring inside that window is flagged in the UI. It never opens an incident and never sends an alert.

Because certificates move slowly, this is the only type that also offers hourly and daily intervals — see Check intervals.

Resolves a name and optionally checks the answer.

  • hostname — the name to resolve.
  • record_type — one of A, AAAA, CNAME, MX, TXT, NS.
  • expected — optional. When set, the answer must match it.
  • nameserver — optional. A specific resolver to query, as an address or address:port. Omitted, the probe uses its own.

The answer assertion rides config.expected rather than the assertions array, so a dns monitor takes no assertions. A lookup that resolves is up; with expected set, it must also match.

The hostname is resolved, never dialled, so it is not an SSRF target. A custom nameserver is dialled, so it is checked like any other target.

Sends ICMP echoes and measures loss.

  • host — a hostname or address.
  • count — 1–10 echoes, default 3.
  • loss_threshold_pct — 0–100, default 100.

Down when loss exceeds the threshold. The default of 100 therefore means “down only on total loss”, which is flap-safe out of the box; lower it to catch partial loss. There is no port — ICMP has none — and no assertions: reachability is the check.

The inverted type. Nothing is dialled; your job calls us, and silence is the failure.

  • period_seconds — how often you promise to beat.
  • grace_seconds — how late a beat may be before absence counts. Must not exceed period_seconds.

Send a beat with a plain request to the monitor’s own URL, which the dashboard shows when you create it:

Terminal window
curl -fsS https://api.wirewatch.io/hb/<token>

GET and POST behave identically, the body is ignored, and a success is 204. The token is the entire credential, so treat it like one; an unknown, paused or deleted token answers 404.

A heartbeat carries no interval, no timeout and no probe locations — configuring any of them is a validation error. Its cadence is period_seconds, which is a much wider range than the active-probe intervals (Check intervals has the bounds). It takes no assertions: a beat arriving is the whole signal.

Use it for cron jobs, backups, batch imports and queue workers — anything whose failure mode is not running rather than not answering.

A synthetic transaction: an ordered sequence of HTTP requests, where later steps can use values extracted from earlier ones. Log in, then fetch the thing only a logged-in user can fetch.

  • steps — 1 to 10, each with a name, a request (method, url, optional headers and body), an extract list and an assertions list.
  • step_timeout_ms — optional per-step bound.
  • total_timeout_ms — optional bound on the whole run.

A step extracts a value from a response — from json, a regex, a header, or the status — binds it to a name, and later steps reference it as {{name}} in a URL, a header value or a body. Secrets are referenced the same way, as {{secret.NAME}}; their values are stored sealed, never in the monitor’s config.

A regex extraction uses the same RE2 pattern subset as a body matches assertion, refused with the same 400 reasons, and every regex extraction of every step shares one complexity limit per check — see Assertions. It returns the first capture group if the pattern has one, otherwise the whole match; a refused or non-matching pattern fails its step.

Assertions live per step, not on the monitor, so multistep takes no top-level assertions — see Assertions. Because one run issues many requests, this type does not offer the fastest interval.