Monitor types

A monitor is a scheduled check executed by a probe. Every type shares the same skeleton — name, tags, probe, schedule, thresholds, alerting — and differs only in what it targets and how its result is graded. This page is the catalogue: pick the lightest type that proves the thing you actually care about.

At a glance

Type	Proves	Key metrics	Graded on	Test button
EUM / Web UI	A real user can complete a journey	Per-step timing, screenshots, video, HAR	Total run time + per-transaction thresholds	Run browser / headless
URL	An HTTP page answers, fast and intact	DNS, TCP, TLS, server, transfer, total, cert expiry	Response time + page size + pattern groups	✅
API	A REST endpoint answers with the right payload	Status code, response time, captured values	Response time + pattern groups	✅
TCP	A port accepts a connection	Connect success, connect time	Response time	✅
UDP	A UDP service answers a real request — or, without a payload, only that the port did not refuse one	Reply received, round-trip time (request/response mode only)	Response time, only in request/response mode	✅
Ping	A host is reachable over ICMP	min / avg / max latency, jitter, packet loss	Response time + jitter thresholds	✅
DNS	A name resolves	Lookup time, resolved addresses	Response time	✅
Database	A database accepts a real query and returns sane data	Connect + query time, result set	Query time + column checks	✅
WebSocket	A real-time stream connects and keeps delivering	Connect breakdown, ping/pong latency, bytes and messages, rates, reconnects	Connect time + expect rules + latency / reconnect / rate thresholds	✅
SNMP	A device reports a healthy OID value	OID values, deltas, expression results	Operator + thresholds, or regexp	✅
WMI	A Windows host reports a healthy WQL value	Query result value	Operator + thresholds, or regexp	✅
System	The probe host itself is healthy	CPU, memory, disk	Per-metric thresholds	—
Workload (Kubernetes / Docker)	A workload runs at its intended replica count, without crashes or resource faults	Replicas, restarts, faults, CPU / memory, pod phases	Readiness + fault rules; ERROR when the platform API cannot answer	Discover & Test on the container host

---

URL monitor

The workhorse synthetic check: one HTTP(S) request, fully instrumented.

What it measures

A URL monitor does not just time the request — it breaks the request down:

Metric	Meaning
DNS lookup time	Time to resolve the hostname
TCP connect time	Time to establish the socket
TLS handshake time	Time to negotiate TLS, with the negotiated TLS version recorded
Server processing time	Time to first byte, once the request is on the wire
Content transfer time	Time to stream the body
Total response time	The value graded against Minor / Major / Critical
HTTP status code	Recorded and validated
Content length	Body size in bytes
SSL certificate expiry	Recorded and alertable before it expires

A slow URL monitor is therefore self-diagnosing: a spike in DNS time is a resolver problem, a spike in TLS time is a handshake or certificate-chain problem, and a spike in server processing time is the application.

What it checks

Beyond the response time, a URL monitor grades three further things — each optional, each contributing its own status:

1. HTTP status — anything outside 2xx/3xx fails the check.
2. Page size — set an expected body size and a comparison operator (> / <). Useful to catch a truncated page or a “success” response that suddenly lost half its content.
3. Pattern groups — regexp checks against the response body. See Pattern groups below.

Connectivity options

Option	Use it for
Basic authentication	User / password protected pages
Client certificate + key	Mutual-TLS endpoints
Skip certificate verification	Internal endpoints with self-signed certificates
Proxy (HTTP/HTTPS, with auth, or a PAC URL)	Probes that must egress through a corporate proxy

Typical setup

Field	Example
Url	https://shop.example.com/
Frequency	1 MIN
Minor / Major / Critical	1000 / 2000 / 3000 ms
Timeout	5000 ms
#Tries	2
Pattern group	Add to cart as a content match

---

API monitor

An API monitor is a URL monitor with full control of the request, aimed at REST endpoints rather than pages.

The request

Field	Description
Method	GET, POST, PUT, DELETE
Endpoint	The full URL of the API
Headers	Any number of name/value pairs — Authorization, Content-Type, custom headers
Body	The payload sent with POST / PUT
Basic auth	User / password
Client certificate + key	For mutual-TLS APIs
Skip certificate verification	For internal endpoints

The verdict

An API monitor is graded on:

1. The HTTP status code — a 5xx is a critical failure regardless of timing.
2. The response time against Minor / Major / Critical.
3. Pattern groups applied to the response body — this is where an API monitor earns its keep. Rather than only proving that /health answered, you extract the values inside the answer and grade them.

Credentials

Never hard-code a bearer token in a header when you can avoid it. Reference a credential configuration or pull the secret from a vault so rotation happens in one place.

---

Pattern groups (URL & API)

Both URL and API monitors can grade the content of the response, not just its timing. Each pattern group extracts one value with a regexp and checks it against its own Minor / Major / Critical thresholds. The monitor status is the most severe of every group and the response time.

Two modes

A group’s regexp works in one of two modes, chosen automatically by whether it contains a capture group:

• Content match — no (capture group). A presence check: the body must contain the pattern. If it does not, the monitor fails. No operator, no thresholds. This is the cheapest way to catch the classic “HTTP 200 with an error page” failure.
• Value extraction — exactly one (capture group). The captured text becomes a value to grade with an operator and thresholds, and it is charted and stored with its own history.

Operators

Operator	The captured value is flagged when it…
number > / number < / number ==	is greater than / less than / equal to the tier value
string == / string !=	equals / does not equal the tier value
string contains / string not contains	contains / does not contain the tier value
datetime older than	parses as a datetime whose age exceeds the tier value (30s, 4m, 1h, 24h)

Leave a tier blank to ignore it — a group can define only a Critical threshold. The match index (idx) picks which occurrence of the pattern to read: 1 is the first, 2 the second element of a repeated field or JSON array. Each row has an enable/disable toggle: a disabled group keeps its settings but is not evaluated and records no history.

Example

An API returning {"status":"ok","queue":42,"updated":"2026-07-30T09:15:00Z"} can be graded with three groups:

Name	Regexp	Operator	Minor	Major	Critical
status	"status":"([^"]*)"	string !=			ok
queue depth	"queue"\s*:\s*(\d+)	number >	100	500	1000
freshness	"updated":"([^"]*)"	datetime older than		1h	24h

For the stored field format, see Monitor Configuration → Pattern Groups.

---

Database monitor

A database monitor connects to a database, runs a query, and grades both how long it took and what came back. It is the only type that reads your data, which makes it the right tool for data-freshness and batch-completion checks that no network check can see.

Supported engines

Engine	Notes
MySQL	Reports timer wait, lock time and CPU time alongside the query duration
Microsoft SQL Server	Reports elapsed time and worker time
PostgreSQL	Reports elapsed time and lock time
Oracle	Reports wait time and CPU time

Those engine-side timings are shown in the raw output of a test, which lets you tell a slow query (high CPU/worker time) apart from a contended one (high lock time).

Connection fields

Field	Description
Type	mysql, mssql, postgres or oracle
IP / Port	Address of the database server
Database	The database (or service) to connect to
User / Password	The monitoring account — read-only, please
Query	The SQL to run
Timeout	Bound applied to connect + query, from 1 s to 30 s

Column checks — grading the result set

A database monitor does not stop at “the query returned”. Each column check picks one value out of the result set and grades it, exactly like a pattern group does for URL/API. The monitor status is the most severe of every check and the query time.

Each row of the Column checks grid holds:

Cell	Meaning
☑	Enable / disable the check — a disabled check keeps its settings but is not evaluated
check name	Used as the chart panel title and the history bucket
column	Which value to read (see selectors below)
row	Which row of the result to read; 1 is the first. Order it in your SQL
operator	How the value is graded — leave on (presence) to only require a non-NULL value
minor / major / critical	Threshold per tier; a blank tier is ignored

Column selectors

Selector	Reads
column_name	The named column, case-insensitive
#2	The second column by position — use this when a join produces duplicate column names
#rows	The number of rows returned, not a cell. Meaningful even on an empty result

Operators

The same operator list as pattern groups, plus a blank (presence) entry that simply requires a non-NULL value at that cell:

(presence) · number > · number < · number == · string == · string != · string contains · string not contains · datetime older than

Built-in verdicts

Some outcomes are graded for you without any threshold:

Outcome	Status
The query returned no rows	CRITICAL
The requested row is past the end of the result	CRITICAL
The cell is NULL	CRITICAL
The column name does not exist, or is ambiguous across a join	ERROR (fix the check)

The distinction matters: CRITICAL is a verdict about your data, ERROR means the check itself is misconfigured.

Examples

Goal	Query	Column	Row	Operator	Thresholds
ETL freshness	SELECT MAX(loaded_at) AS loaded_at FROM facts	loaded_at	1	datetime older than	maj 4h, cri 6h
Dead-letter queue growth	SELECT COUNT(*) AS n FROM dlq	n	1	number >	min 1, maj 50, cri 500
Batch finished	SELECT status FROM jobs ORDER BY id DESC LIMIT 1	status	1	string !=	cri DONE
Replica present	SELECT * FROM replicas WHERE lag_s < 30	#rows	—	number <	cri 1

---

WebSocket monitor

The only type that holds a connection open. A URL monitor proves an endpoint answers once; a WebSocket monitor proves a stream is alive — the upgrade succeeds, the right frames arrive, and data keeps flowing.

Every scheduled run is one complete session: connect, upgrade, optionally authenticate and send messages, validate what comes back, then close. Counters such as reconnects, connection duration and message rate therefore describe that single session, not an uptime since boot.

Connection fields

Field	Description
URL	A ws:// or wss:// endpoint
Authentication	None, Basic, Bearer token or API key header — plus custom headers and cookies
Subprotocols	Sec-WebSocket-Protocol values to offer during the upgrade
TLS	Verification toggle, client certificate, CA, SNI override, proxy

Timing — the part that catches people out

Four independent fields. Confusing them is the usual cause of a monitor that alerts too slowly or reports empty traffic counters:

Field	Unit	Default	What it bounds
Connect timeout	ms	10000	DNS + TCP + TLS + upgrade. A dead endpoint fails after this, whatever the rest are set to
Hold session	s	unset	How long the socket stays open once connected, giving bytes, messages and rates a window to measure over
Receive within	s	the connect timeout	Deadline for the expected messages
Ping interval + pong timeout	s / ms	1 s / 5000 ms	Ping spacing, and how long a pong may take. Both inert until Ping count is set

The hold window sits on top of the connect timeout rather than inside it, so lengthening it never delays a down alert.

Without a hold window the session closes as soon as its criteria are met — right after the upgrade when there are no expected messages and no pings. That is fine for a connectivity check, but the Traffic panel stays near zero and the message rates get divided by a session that lasted milliseconds. Set a window whenever you grade on message rate.

#Tries replays the whole session, not just the connect, so a 30 s window at the default 2 tries costs up to 60 s of wall clock. The probe clamps the window to fit inside the schedule interval, and the form warns you when it will.

Validating messages

Outgoing messages are sent on connect, after N seconds, or periodically, as text, JSON or binary — to authenticate, subscribe to a channel or request a heartbeat.

Expect rules grade what comes back: exact text, contains, regexp, valid JSON, or a JSONPath expression compared with eq / ne / contains / exists / gt / lt / regex. Every non-optional rule must be satisfied before the Receive within deadline or the run fails with a validation error.

The verdict

A run is healthy when the TCP connection succeeds, TLS succeeds (for wss://), the upgrade returns 101 Switching Protocols, authentication is accepted, every non-optional expect rule is satisfied in time, and ping/pong stays under its threshold.

Graded on	Field
Connection establishment time — DNS + TCP + TLS + upgrade	Minor / Major / Critical
Ping/pong latency	Alert if latency >
Reconnect count	Alert if reconnects >
Incoming message rate	Min / Max message rate
Certificate expiry and identity	Check expiry / Alert on change

---

Network monitors

TCP

The lightest possible proof that a service is listening: dial the host and port from the probe, and record whether the connection succeeded and how long it took.

Field	Description
Destination IP / hostname	The target
Port	The port to dial
Timeout	Milliseconds before giving up (default 5000)

Use it for the things that have no HTTP surface — database ports, message brokers, LDAP, SMTP — and as the first triage step when a URL monitor turns red: if TCP is fine and URL is not, the network is not your problem.

TCP is a handshake, so a successful connect really does prove something answered. UDP has no handshake, and that changes the whole check — which is why it is a separate monitor type with its own two modes, below.

UDP

UDP is connectionless: there is nothing to accept, so there is nothing to time. A UDP monitor therefore runs in one of two modes, and which one it is in decides what its status and its response time are allowed to mean. The Check mode dropdown on the monitor form picks it.

	Reachability only	Request / response
What is sent	one meaningless byte	a payload you configure, valid for the protocol on that port
What proves a failure	an ICMP port unreachable came back	no reply, or a reply that does not match the expectation
Silence means	healthy	failed
Response time	not measured	a real round trip
Minor / Major / Critical	inert — pinned, never graded	live, default 50 / 100 / 150 ms

Request / response fields

Choosing anything other than Reachability only reveals the payload block:

Field	Description
Payload format	Text (accepts the escapes \r \n \t \0 \xNN) or Hex
Payload to send	The datagram itself. It must be valid for the protocol on that port — anything the service ignores reads as down.
Expected reply	Any reply, Contains text, Contains hex, or Matches regex
Expected value	What to look for, for the three modes that need one
Response time thresholds	Minor / Major / Critical, in milliseconds

Any reply at all is already the proof reachability mode cannot give, so Any reply is a perfectly good expectation — tighten it only when a wrong-but-present answer matters.

Malformed input is refused at save time rather than raising an EXCEPTION on every cycle afterwards: an odd number of hex digits, an invalid escape, an uncompilable regex and a non-numeric threshold are all rejected by the form.

Protocol templates

The Check mode dropdown also carries ready-made requests. Picking one fills in the payload, the expectation and — while the field is still empty — the default port, then leaves everything editable:

Template	Port	Sends	Why the reply proves it is up
DNS query	53	A standard query for the root NS record	Any response, REFUSED included, means the resolver answered
NTP client request	123	A mode-3 client request	Any reply means the time service answered
STUN binding request	3478	A binding request	The reply carries back the same magic cookie
TFTP read request	69	A read request for a file that need not exist	A live server answers DATA or ERROR; either proves it is up
memcached stats	11211	The stats command	A healthy server replies with STAT lines
Echo (RFC 862)	7	A short marker payload	The service sends the payload straight back
Custom payload	—	Whatever you type	Whatever you choose to expect

Ping

ICMP echo request/reply. It answers a different question from TCP: not “is the service up” but “is the host reachable, and is the path healthy”.

Metric	Meaning
min / avg / max latency	Round-trip time across the sent packets
jitter	Variation between successive round trips — graded against its own Minor / Major / Critical thresholds
packets sent / received / lost	Packet-loss rate

Jitter and loss are what make Ping worth running alongside everything else: they turn a vague “the app feels slow” into a measured network problem.

DNS

Resolve a name from the probe and measure how long it took. Cheap, and it catches a whole class of outages — a resolver that went away, a record that was deleted, a TTL change that hurt — long before they surface as an application error.

---

Device monitors

SNMP

Poll an OID on a network device: v1, v2c or v3 (with user, auth and privacy credentials). The value is turned into a status by an operator: number >, number < or regexp.

SNMP also supports math expressions that combine several OIDs into one computed value — total interface traffic as oidIn + oidOut, memory percentage as (used / total) * 100 — and deltas between polls, which is how you make sense of monotonically increasing counters.

WMI

The Windows equivalent: run a WQL query in a namespace (default root\CIMV2) and grade the returned value with the same operators.

Both types ship a set of assistants — suggested OIDs/queries verified live on the target, a subtree/class browser, reusable templates, and a Test all button. See SNMP & WMI evaluation for the full walkthrough.

Workload (Kubernetes & Docker)

A workload monitor watches one Kubernetes Deployment, StatefulSet, DaemonSet or CronJob, or one Docker container or compose service, through the platform’s own API. It belongs to a container host — the cluster or the Docker host — which holds the connection and discovers the workloads you can adopt.

It answers the question a URL monitor cannot: not “is the page slow” but “is the application running at the replica count I asked for, and if not, why” — CrashLoopBackOff, ImagePullBackOff, an OOM kill, an eviction, a failed CronJob run. When the API itself cannot be reached or refuses the credentials, the status is ERROR, which outranks CRITICAL. See Container monitoring for setup, grading and limits.

---

EUM / Web UI

The heaviest and most faithful type: a scripted browser journey, executed on a real Chrome, Firefox or Edge, timed step by step.

Capability	Description
Transactions	Wrap each step of the journey; every step gets its own timing and thresholds
Evidence	Screenshot per step, full video of the run, HAR capture of every request
2FA	TOTP support (RFC 6238 — 6 digits / 30 s / SHA-1) so a login with MFA can be scripted
Proxy	Route the browser through a proxy
Visual similarity	Compare rendered pages against a reference

An EUM monitor is the only type that measures what the user actually experiences, front-end rendering included. It is also the most expensive to run and the most brittle to maintain — script the two or three journeys that carry your revenue, and cover the rest with URL and API monitors.

See the EUM Monitor page for the full specification, and Monitor operations for the browser and headless run modes.

---

System

Self-monitoring of the probe host: CPU usage, memory usage and disk usage, each with its own thresholds. Use it to know that the machine doing your monitoring is itself healthy — a saturated probe reports false latency for everything it runs.

---

Choosing a type

A practical ladder, cheapest first:

1. Ping — is the host there at all?
2. TCP — is something listening on the port? (UDP, and only with a payload — see UDP)
3. DNS — does the name still resolve?
4. URL — does the page answer, fast, with the right content?
5. API — does the endpoint return the right values?
6. Database — is the data behind it correct and fresh?
7. EUM — can a real user actually complete the journey?

Start at the top and add rungs where the answer matters. Each layer narrows down where a failure lives, which is what turns an alert into a diagnosis.

WebSocket sits outside that ladder. It answers a question none of the others can: not “did a request succeed” but “is the stream still delivering”. Reach for it when the thing you sell is a live feed — prices, telemetry, chat, notifications — where a socket that connects fine and then goes silent is the failure your users notice first.

See also

• Testing a monitor — run any check live before you save it
• Monitor operations — create, run, edit and maintain monitors
• Monitor Component Deep Dive — scheduling, concurrency and storage internals
• Monitor Configuration — every field, including the stored patterns format
• SNMP & WMI evaluation — operators, suggestions, browsers and templates
• Container monitoring — Kubernetes and Docker workloads: setup, grading and limits
• EUM Monitor — browser journeys, TOTP and vault integration
• How thresholds work — severity model and status computation

Translations

• fr: Types de moniteurs