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 ofGET,POST,PUT,PATCH,DELETE,HEAD.url— an absolutehttp(s)URL. Any other scheme is rejected.headers— optional request headers.body— optional request body.followRedirects— defaults totrue.
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 to443.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_daysis 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 ofA,AAAA,CNAME,MX,TXT,NS.expected— optional. When set, the answer must match it.nameserver— optional. A specific resolver to query, as an address oraddress: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–10echoes, default3.loss_threshold_pct—0–100, default100.
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.
heartbeat
Section titled “heartbeat”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 exceedperiod_seconds.
Send a beat with a plain request to the monitor’s own URL, which the dashboard shows when you create it:
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.
multistep
Section titled “multistep”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 aname, arequest(method,url, optionalheadersandbody), anextractlist and anassertionslist.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.