Skip to main content
A check is a named rule (or set of rules) that a host must satisfy. Checks live under Acceptance to Run → Checks in the Luumen UI. This page walks through creating one.

​
Anatomy of a rule

Each rule in the rule builder is an equation with three parts:
  • Left field — a host property (e.g., MEMORY, OS Version, Kernel Version, or an application-specific property like SAP Components).
  • Operator — a comparison (equals, not equals, greater than, less than, contains, does not contain, and so on; the available operators depend on the data type of the property).
  • Right value — what to compare against (e.g., 8, Linux, SLES 15).
Multiple rules can be combined with AND and OR. Group rules in parentheses (the UI calls these “AND/OR” blocks) to express logic like “RAM must be ≥ 12 GB AND (CPUs ≥ 3 OR vendor = AWS)”.

​
Create a check

1

Open the checks page

Go to Acceptance to Run → Checks and click Add custom check (or pick from Preset checks if Luumen ships a built-in that matches your need).
2

Name and describe it

Give the check a clear, specific name (e.g., “Minimum memory for production app servers”) and a one-line description of what it verifies. The name is what your team sees in the assignment picker, so make it descriptive enough to choose by.
3

Set the access level

Choose whether the check applies to All clients (available across your workspace) or Only for this client. For most enterprise customers there’s only one client, in which case the choice is effectively cosmetic.
4

Build the rule

In the Condition panel, click + AND/OR to add a rule and pick the left field, operator, and right value. Add more rules and group them as needed.
5

Assign it to one or more groups

Optionally pick the host groups this check should apply to from the Assign check to host group(s) picker. You can also assign later from the group’s detail page — see Assigning checks.
6

Save

Click Done. The check now evaluates on the next agent run for every host in the groups you assigned.

​
A worked example

Suppose your standard for a production app server is “at least 12 GB of RAM, at least 3 CPUs, running Linux, and either AWS or on-prem hardware”. In the rule builder, that’s: 
CPUs > 3
AND
RAM > 12
AND
OS version Contains Linux
AND
(vendor = AWS OR vendor = on-prem)
The exact field names will match what the agent reports for your environment — confirm them in Acceptance to Run → Checks → [Check name] after creation.

​
Choosing the right left field

A rule can only reference a property that’s actually been reported for the target hosts. If you write a rule against a property the agent doesn’t collect, every host in scope will return Error rather than Pass or Fail. To confirm a property is collected:
  1. Open Hosts → All hosts and click any host in the target group.
  2. Look for the property in the detail view.
  3. If it’s missing, see Missing properties.
If a property you want to check on doesn’t exist yet, raise it with your account team. Adding new properties typically requires an agent update — see What the agent collects.

​
Operators

The operators available depend on the property’s data type:
TypeOperators
Numeric=, ≠, >, <, ≥, ≤
Stringequals, not equals, contains, does not contain
Booleanis true, is false
Lists (e.g., installed packages)contains, does not contain, count >, count <
If you don’t see an operator you expect, double-check the property’s data type — sometimes a numeric value comes through as a string and needs a string operator, or vice versa.

​
After saving

Saved checks live in the Checks list. From there you can:
  • Edit — adjust rules, name, description, or group assignments.
  • Disable — keep the check definition but stop running it. Useful for staging changes.
  • Delete — remove the check entirely. Historical results stay in the database but no new evaluations are made.
When you save a new check or change one, results refresh on the next agent run — not immediately. See Compliance scans overview for the timing.