Skip to main content
A compliance scan is the evaluation of a host against the set of checks assigned to its groups. Scans run automatically every time the agent reports fresh data — there’s no separate “scan” step beyond the agent run itself. This page explains how scans are triggered, where to view results, and how the terminal and web interfaces relate.

​
How scans run

1

Agent collects data

On its scheduled cycle, the agent connects to every host, gathers properties, and reports them to the Luumen API. See What the agent collects.
2

Luumen evaluates checks

For each host, Luumen finds every group the host belongs to, then every check assigned to those groups, and evaluates each rule against the most recent properties.
3

Results update in the UI

Pass, fail, and error counts update on the Acceptance to Run → Overview page and at the host-detail level.
Because evaluation is automatic, the cadence of scans is determined by the agent’s schedule. If you want results to refresh faster than the schedule allows, run the agent manually on the Patch server (see Scheduling runs).

​
Terminal vs web

Compliance results are surfaced in two places: the web UI and an interactive terminal interface on the Patch server. These are two views of the same data, not two different scan engines.
SurfaceWhat it’s for
Web UIThe day-to-day view. Schedule-driven, automatic — the agent runs on its interval and the dashboard reflects the latest state. Use this for ongoing operations, reporting, and stakeholder reviews.
TerminalManual, on-demand. Useful when you’ve just changed a check or fixed a host and want to validate without waiting for the next scheduled run. The terminal triggers an agent run and displays the same pass/fail output the web UI would.
Both surfaces read from the same underlying scan results. Findings, status changes, and history persist regardless of which interface initiated the run.

​
Anatomy of a scan result

For each host in a group with assigned checks, a scan produces three categories of result:
  • Passed — the rule evaluated true against the latest properties.
  • Failed — the rule evaluated false. The UI surfaces the expected vs. actual values to make debugging easy.
  • Error — the rule could not be evaluated. This is typically because the required property was missing from the host (e.g., a memory check on a host the agent couldn’t reach for memory data on the last run).
The Overview page shows roll-ups at the group level and a “Needs attention” list of hosts with recent failures or errors. Click any host or group to drill in.

​
Last-N-checks indicator

The Overview page shows a sparkline-style indicator of the last 12 check runs per host. Reading the indicator:
  • Mostly green with a recent red — a regression to investigate.
  • Mostly red — a check that’s been failing consistently. Either the host needs remediation or the check rule needs adjustment.
  • All grey (“Not checked”) — the host hasn’t been part of a successful scan recently, usually a connectivity or credential issue.

​
Where to start

If you’re setting up compliance for the first time:

Create your first check

Build a rule using the rule builder — left field, operator, right value.

Assign it to a group

Attach the check to the right host group so it only runs where it applies.

Review results

Watch results land on the Overview page and export reports for stakeholders.

Group your hosts

If you haven’t already, create host groups for your major host classes.