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

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:

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

Typical setup

API monitor

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

The request

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

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:

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

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

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:

Column selectors

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:

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

Examples

Network monitors

TCP and UDP

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.

Use them 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.

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”.

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.

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.

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 / UDP — is something listening on the port?
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.

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
• EUM Monitor — browser journeys, TOTP and vault integration
• How thresholds work — severity model and status computation

Translations

• fr: Types de moniteurs