Skip to main content

Endpoint Checks

What Endpoint Checks Do​

Endpoint Checks continuously verify whether the software, services, files, and certificates your endpoints need are present and healthy. They help you find an endpoint that has an application installed but stopped, a missing certificate, or another condition that needs attention.

Open Orchestration > Endpoint Checks to manage check policies and review fleet results. You can also open an endpoint and select its Checks tab to see the checks that apply to that endpoint.

Policies and Checks​

A check policy targets one platform, either Windows or Linux. Assign the policy to one or more tags to choose which endpoints are evaluated. The policy evaluates on a schedule, with an interval of 60 minutes by default. You can choose another interval when you create or edit the policy.

The available check types are:

  • Application Catalog: Windows only. Require one or more catalog applications to be installed.
  • Windows Service / systemd Unit: Verify that a Windows service or Linux systemd unit exists, is running, or has the required startup state.
  • Registry Key/Value: Windows only. Check whether a registry key or value exists, or compare its value.
  • File / Path: Verify that a file, directory, binary, or other path exists, or meets the selected condition.
  • Log Content Poll: Poll a log file for a pattern over a lookback window and evaluate the number of matches.
  • Process Running: Verify that a named process is running or is not running.
  • Scheduled Task / Cron Entry: Verify that a Windows scheduled task or Linux cron entry exists and is enabled when required.
  • Certificate Presence: Check for a certificate in the selected Windows certificate store or Linux certificate directory.
  • Agent Tag: Require or forbid a tag on the endpoint.

Each policy can contain checks for its selected platform. Checks that do not apply to that platform are not available in the policy editor.

Criteria Groups​

Checks live inside criteria groups, shown as numbered groups in the policy editor. A group passes only when every check in it passes. The policy passes when at least one of its groups passes. In other words, each group describes one complete way for an endpoint to satisfy the policy, and the endpoint only needs to match one of them.

For example, suppose an endpoint may use either of two approved antivirus products. Create two groups, each containing one Process Running check for one of the antivirus processes. An endpoint running either process satisfies one of the groups, so the policy passes. To require several conditions together, put those checks in the same group.

Not Required Checks​

When a policy passes through one group, the checks in its other groups did not take part in the result. Those checks are marked Not required rather than Passed or Failed, and they are left out of the failing count. This is why an endpoint can show a policy as Passed while a check listed under it reads Not required: that check belonged to a group the endpoint did not need to satisfy.

A check marked Not required never affects the endpoint health score. Because a policy passes when any one of its groups passes, a policy that passes through one group applies no health penalty, even if checks in its other groups failed. The health penalty is applied only when the policy as a whole is failing (see Health Penalties).

Per-Platform Configuration​

Use the full path or platform-specific name expected by the endpoint. For a File / Path check, enter the path as it appears on the target platform. Windows paths can use a drive letter, such as C:\Program Files\Example\agent.exe, while Linux paths use the filesystem format, such as /etc/example/agent.conf.

For a Windows Service / systemd Unit or Process Running check, enter the name of the service or process. A trailing file extension such as .exe is optional: the check matches whether or not you include it, and the policy editor shows how the name will be matched as you type. A File / Path check is different, because there the extension is part of the path and must be entered exactly.

For Certificate Presence, the store value identifies where TridentStack Control should look for the certificate:

  • On Windows, you can enter the short Microsoft Management Console store name, such as Root, or the full store path, such as LocalMachine\Root.
  • On Linux, enter a certificate directory, such as /etc/ssl/certs.

Choose a store or path that exists on every endpoint targeted by the policy. A check fails on any endpoint where the configured store or path does not exist, so a value present on some endpoints but not others will produce mixed results.

The Agent Tag Check​

The Agent Tag check is evaluated by TridentStack Control against the endpoint's current tags. The endpoint does not evaluate this check locally.

Use it when a policy should require an endpoint to have a particular tag, or when it should fail if that tag is present. This is useful for confirming that an endpoint remains in the intended group or for preventing a check policy from passing on an excluded endpoint.

Health Penalties​

Each check policy has a single health penalty. When the policy is failing, TridentStack Control deducts that amount from the endpoint health score, once, no matter how many of the policy's checks failed. The value can be from 0 to 100.

A policy deducts nothing while it is passing or has not yet been evaluated. Because a policy passes when any one of its groups passes, checks in the groups an endpoint did not need to satisfy never lower its score (see Not Required Checks).

Set the penalty to 0 when a policy should be report-only. Its results still show whether each check passed or failed, but the policy does not lower the endpoint health score.

New check policies start with a penalty of 0. You can set or change a policy's penalty in the policy editor.

Results​

Check results use three statuses:

  • Passed: The endpoint meets the check's criteria.
  • Failed: The endpoint does not meet the check's criteria.
  • Pending: The check has not produced an evaluation result yet.

In Orchestration > Endpoint Checks, use the Policies tab to manage policies and the Results tab to review check results across your endpoints. For an endpoint-specific view, open the endpoint's Checks tab.

When you assign a new policy to a tag, its result remains Pending until the endpoint reaches the next evaluation. After that evaluation, the result changes to Passed or Failed based on the endpoint's current state.

Failure Alerts and the Compliance Report​

Alert when a policy starts failing​

Each check policy can send an alert the moment an endpoint starts failing it. Turn this on with the Alert on failure switch in the policy editor. You can also set a per-policy reminder interval that controls how long TridentStack Control waits before re-alerting an endpoint that stays failing, which overrides the fleet-wide default. Every policy's alert switch is also listed in one place under Settings > Notifications. See Notifications for delivery channels, the fleet-wide reminder interval, the summary that groups a large burst of failures, and the scheduled compliance summary.

The Report tab​

The Report tab in Orchestration > Endpoint Checks shows one row per active policy with its in-scope, passing, and failing endpoint counts. The passing count includes only endpoints that have evaluated and passed, so an endpoint that has not been evaluated yet is not counted as passing.

Open a policy to see each failing endpoint along with the specific checks it is failing, paged for large fleets. Select Download CSV to export the current compliance state. From the summary the export covers every failing endpoint across the fleet; from inside a policy it covers just that policy, which is the one to use when a fleet-wide export is too large.