Skip to main content
A check on its own does nothing — it has to be assigned to one or more host groups before it runs. Once assigned, the check evaluates against every host currently in those groups on every agent run.

​
Two ways to assign

You can assign a check at creation time, or from the group’s detail page. Both produce the same result.

​
When creating the check

In the Create check modal, the Assign check to host group(s) field lets you pick groups directly:
  1. Open Acceptance to Run → Checks → Add custom check.
  2. Build your rule (see Creating checks).
  3. In the Assign check to host group(s) picker, select one or more groups.
  4. Click Done.
This is the right path when you’re authoring a new check that already has a clear target audience.

​
From a group’s detail page

If a check already exists, attach it to a group from the group side:
  1. Go to Hosts → Host groups → [Group name].
  2. Click Assign check.
  3. Pick the check from the list and confirm.
Use this path when you’re adding an existing check to a new group (for example, you’ve just created a “Sandbox” group and want it to inherit checks that already apply to “Non-production”).

​
One check, many groups

A check can be assigned to as many groups as you want. The check evaluates once per host per agent run, regardless of how many of its assigned groups that host belongs to. There’s no penalty (in compute or in result clarity) for overlapping group memberships.

​
Picking the right granularity

Two failure modes to avoid:
  • One giant group. If every check is assigned to “All hosts,” every check produces an error for every host that doesn’t have the relevant property. Your Overview page fills with red and the signal gets lost in the noise.
  • One group per host. If you create a group per host, group-level rollups stop being meaningful and you’ve reinvented per-host assignment.
A pragmatic middle ground:
  • One group per server role (e.g., “Application servers”, “Database primaries”, “Web tier”, “Cache nodes”).
  • One group per environment (e.g., “Production”, “QA”, “Sandbox”).
  • Cross-cutting groups for vendors when you need them (e.g., “AWS”).
If you’ve enabled an application integration like SAP, role groups for that landscape (e.g., “SAP application servers”, “HANA primary”) fit naturally in the same pattern. Assign each check to the groups where the rule’s left field will actually be present on every member. That keeps the Overview page’s pass/fail signal honest.

​
Removing an assignment

To stop a check from running against a group, edit the check and remove the group from its assignment list, or open the group and remove the check. Either side works. The check itself continues to exist for any remaining group assignments. Historical results for hosts that fell out of scope are preserved.

​
When changes take effect

Like everything else in Luumen, assignment changes apply on the next agent run. If you’ve just attached a new check to a group and want to validate it, either wait for the next scheduled run or trigger one manually from the Patch server. See Scheduling runs.