Device Monitor Board
The Monitors section on a machine's Agent Details page answers one question at a glance: which health checks apply to this device right now, and how is it doing on each? It lists every enabled monitor whose target tags cover this machine, joined to that monitor's most recent outcome — the state, the value the device actually observed, the threshold it compared against, the severity and the time the check last ran — with a per-device Run Now for a fresh evaluation.
Author monitors, set thresholds and work alerts on the Monitoring & Alerts pages. This page is the other end of the telescope — one device, every monitor that touches it, and each monitor's latest result on that machine. Nothing here creates or edits a monitor.
Where to find it#
Open any agent from the Agents list, then choose Monitoring → Monitors in the Agent Details side navigation. The card header reads Monitors with the sub-line "Latest outcome of every monitor targeting this device". The board updates live: when the device reports a new result, the row changes without a page reload, and a Refresh button re-pulls the whole board on demand.
Viewing the board requires the Helpdesk role or above. The per-row Run Now button appears only for Operator and Admin. See Roles & Permissions.
Which monitors appear#
Coverage is derived from tags at the moment you open the board, not from any per-device assignment. A monitor shows up here when it is enabled and its target tags match this device's effective tags — whether those tags were set by hand or applied by an automatic tagging rule. Consequences worth knowing:
- Tag a machine so it matches a monitor and that monitor joins the board immediately — there is nothing else to assign.
- A disabled monitor drops off the board entirely; disabling is the clean way to stop a check from applying to a device.
- A device that carries no monitor-matching tags shows an empty board with "No monitors currently target this device" — that is normal, not an error.
- A monitor that targets the device but has never reported still appears, in the Not Evaluated state, so "we have never heard back" is visible rather than hidden.
Reading a row#
Each row is one monitor and its latest result on this device. The board keeps only the newest result per monitor — it is a live status board, not a history log. The columns are:
| Column | What it shows |
|---|---|
| Monitor | The monitor's name, as authored on the Monitoring page. |
| State | The latest outcome badge (see the state table below). For Error and Not Applicable the device's own explanation is shown beside the badge. |
| Observed Value | The exact value the device compared against the threshold, verbatim. A dash (—) means the monitor has not reported a value yet. |
| Threshold | The monitor's current threshold, with a Stale marker when the device last evaluated against a different one (see Drift), or Up to date when it matches. |
| Severity | The monitor's severity — Info, Warning or Critical — carried onto any alert it raises. |
| Last Evaluated | When the device actually ran the check, in the device's local time. A dash means it has not run yet. |
| Actions | Run Now for Operators and Admins (see Run Now). |
Above the table, a row of state filter chips — All, Pass, Fail, Error, Not Applicable, Not Evaluated — each carries a live count, and a "Showing N of M monitors" line tells you how many rows the current filter leaves. Click a chip to narrow the board to that state; click All to clear the filter.
What each state means#
The device — not the server — decides the outcome: it runs the check on its own schedule and reports exactly one state. Polarity is fixed, and it is the same as on the Monitoring page: the monitor's condition being true means Fail, because you author a monitor's condition to describe the bad state.
| State | Meaning |
|---|---|
| Pass | The monitor's condition evaluated false — this device is healthy for this monitor. |
| Fail | The condition evaluated true — this device is in the state the monitor watches for. This is what drives an alert, subject to the monitor's hysteresis. |
| Error | The monitor's scan could not complete — it threw, timed out, or could not be executed on this device. The device's error text is shown beside the badge. |
| Not Applicable | The device could not observe the value at all, so there was nothing to compare. This is not a pass — the reason the device gives (for example, a check that does not apply to that platform) is shown beside the badge. |
| Not Evaluated | The monitor targets this device but has not reported a result yet — newly targeted, or the device has not reached its next evaluation. Rendered as a badge, never a blank row. |
Only Pass and Fail feed a monitor's fire/clear streak. An Error or Not Applicable result counts as neither, so a device that cannot run a check will never trip — or clear — an alert on that basis. That is why the two are separate states with their own colours rather than being folded into Fail or Pass.
Threshold drift — the "Stale" marker#
A device evaluates a monitor against whatever threshold it held at the time it ran. If you later edit that monitor's threshold on the Monitoring page, the device's last result was produced against the old value until it next evaluates. The board makes that honest: the Threshold column shows the monitor's current threshold, and adds a ⚠️ Stale marker when the device's last evaluation used a different one. Hover it to see both values — "Evaluated against threshold 'X'; the monitor's threshold is now 'Y'."
Stale is purely informational: it never changes the displayed state. It just tells you the row is a result against a threshold you have since moved, so you know to wait for the next evaluation (or press Run Now) before trusting it. A monitor that has never reported shows neither Stale nor Up to date, because there is no prior threshold to compare with.
Evaluated time vs. reported time#
The Last Evaluated column is the device's local time when the check actually ran — not when the server received the result. Those two can differ a lot: a device that was offline runs its checks locally and delivers the backlog when it reconnects, so a result can be recorded by the server well after the device evaluated it. The board deliberately shows the evaluation time, because that is the moment the observed value was true. This is the same principle behind offline compliance evaluation: devices keep checking even when the server is unreachable, and catch up on reconnect.
Run Now — re-check one device#
Run Now (Operator or Admin) forces an immediate evaluation of that one monitor on this device only — handy right after you fix something, or to confirm a Stale row against the current threshold. It differs from the fleet-wide Run on the Monitoring page, which evaluates a monitor across every device it covers.
- If the device is online, the evaluation is dispatched straight away and you see "Evaluation dispatched to this device".
- If the device is offline, the button still works: the run is queued and executed when the device reconnects — "Device is offline — the evaluation was queued and will run on reconnect".
The board does not reload the instant you press the button; the fresh row arrives on its own when the device actually reports back, so what you see is always a real result rather than a stale one re-rendered. Each Run Now is written to the audit log with your name and the monitor it evaluated.
Reading the board over REST#
The same board is available as a read-only endpoint, so you can pull one device's monitor status into a script or a dashboard. It returns the identical data the UI shows, so the page and the API never disagree.
# Every monitor targeting this device, each with its latest result
GET /api/agents/{agentId}/monitor-results
Reading requires the Helpdesk role or above. An empty list with a 200
is valid — it means no monitor currently targets that device — while an unknown
agentId returns 404. Each item carries the fields behind the columns
above, plus both threshold inputs so you can compute drift yourself:
| Field | Meaning |
|---|---|
monitorName, monitorId | The monitor this result is for. |
state | 0 Not Evaluated, 1 Pass, 2 Fail, 3 Error, 4 Not Applicable. |
observedValue | The value the device compared, verbatim; null when nothing was observed. |
currentThreshold | The monitor's threshold today. |
thresholdAtEvaluation | The threshold the device actually used. currentThreshold != thresholdAtEvaluation is the drift (Stale) indicator. |
severity | 0 Info, 1 Warning, 2 Critical. |
errorMessage | The device's explanation for an Error, or the reason for Not Applicable; otherwise null. |
evaluatedAt | When the device ran the check (device local time). Order by this when you care which observation is newer. |
reportedAt | When the server recorded the report (server local time). May be much later than evaluatedAt after an offline backlog. |
To force an evaluation from a script, use the monitor-level on-demand run on the
Monitoring & Alerts endpoints
(POST /api/monitors/{id}/run), which evaluates the monitor across every device it
covers. See the API Reference.
Related pages#
- Monitoring & Alerts — author monitors, set thresholds and hysteresis, and work the alerts they raise.
- Agent Details View — the page this board lives on, alongside inventory, metrics and remote actions.
- Agent Tags — the tags that decide which monitors cover a device.
- Automatic Tagging Rules — apply those tags by rule so coverage keeps itself current.
- Compliance Evaluation Lifecycle — the related model for how offline devices keep evaluating and catch up.
- Audit & SIEM — where a per-device Run Now is recorded.