Alert Rules

Alert rules let Ordyn turn endpoint telemetry into actionable endpoint alerts.

Use them when you want Ordyn to keep checking a condition, show the result on the endpoint, and make active problems visible in the endpoint sidebar.

What they are for

Alert rules are intended for operational and security checks such as:

• high uptime
• high memory usage
• high system drive usage
• disabled Microsoft Defender settings
• disabled Secure Boot
• disabled Windows Firewall profiles
• disabled Credential Guard, Device Guard, HVCI, LSA protection, UAC, or Remote Desktop safeguards
• insecure SMB client or server settings
• custom checks implemented by endpoint scripts

Alert rules do not remediate endpoints. They record whether a condition is healthy, triggered, or errored.

Where alert rules live

Alert rule definitions live in Library > Alert Rules.

The definition contains:

• name
• optional description
• source type
• evaluation interval
• value path
• value type
• comparator
• threshold value
• severity
• enabled state

Supported value types are:

• number
• string
• boolean

Supported comparators are:

• above
• below
• equal
• not_equal

above and below are only valid for number values.

Rule sources

Ordyn currently supports two alert rule sources.

Internal

Internal alert rules are built into Ordyn.

They are evaluated by Ordyn from the endpoint's current system status and security posture data. They do not run a script on the endpoint.

Internal rules currently include:

Rule	Platforms	What it checks
Uptime too high	Windows, Linux	Endpoint uptime in days
Memory usage too high	Windows, Linux	Used memory percentage
System drive usage too high	Windows, Linux	Usage percentage for a configured drive path or mount
Secure Boot disabled	Windows, Linux	Reported Secure Boot state
Microsoft Defender service disabled	Windows	Defender service state
Microsoft Defender AV disabled	Windows	Defender antivirus state
Microsoft Defender real-time protection disabled	Windows	Defender real-time protection state
Microsoft Defender signatures out of date	Windows	Defender signature freshness state
Microsoft Defender signature age too high	Windows	Defender signature age in days
Microsoft Defender tamper protection disabled	Windows	Defender tamper protection state, when reported
Microsoft Defender cloud protection disabled	Windows	Defender cloud-delivered protection state, when reported
Credential Guard not configured	Windows	Credential Guard configured state, only when the endpoint reports compatibility
Credential Guard not running	Windows	Credential Guard running state, only when the endpoint reports compatibility
Device Guard / VBS not configured	Windows	Device Guard / VBS configured state, only when the endpoint reports compatibility
Device Guard / VBS not running	Windows	Device Guard / VBS running state, only when the endpoint reports compatibility
HVCI not running	Windows	HVCI running state, only when the endpoint reports compatibility
Memory Integrity not running	Windows	Canonical Memory Integrity runtime state
LSA protection disabled	Windows	LSA protection state
LSA protection not running	Windows	LSA runtime verification state
UAC disabled	Windows	UAC enabled state
UAC secure desktop disabled	Windows	UAC secure desktop prompt state
Cached Windows credentials enabled	Windows	Cached logon state
LM hash storage enabled	Windows	LM hash storage protection state
Remote Desktop enabled	Windows	Remote Desktop enabled state
Remote Desktop NLA disabled	Windows	Remote Desktop Network Level Authentication state
SMB1 client enabled	Windows	SMB1 client protocol state
SMB1 server enabled	Windows	SMB1 server protocol state
SMB client signing not required	Windows	SMB client signing requirement
SMB server signing not required	Windows	SMB server signing requirement
SMB insecure guest logons enabled	Windows	SMB client insecure guest logon state
SMB client encryption not required	Windows	SMB client encryption requirement
SMB server allows unencrypted access	Windows	SMB server rejection of unencrypted access
SMB client NTLM not blocked	Windows	SMB client NTLM blocking state
SMB2 and later server protocol disabled	Windows	SMB2-or-later server protocol state
SMB authentication rate limiter disabled	Windows	SMB invalid-authentication delay; configure an equal threshold of 0
Windows Firewall domain profile disabled	Windows	Domain profile firewall state
Windows Firewall private profile disabled	Windows	Private profile firewall state
Windows Firewall public profile disabled	Windows	Public profile firewall state

The System drive usage too high template has one required parameter:

• Drive path or mount, for example C: on Windows or / on Linux

Internal rule evaluation requires a current system status snapshot. If the endpoint has no current system status, or the snapshot is stale, Ordyn records the rule as an error instead of silently ignoring it.

Script

Script alert rules run an existing endpoint script and evaluate the script result.

The selected script must:

• target endpoints
• produce JSON output
• target an endpoint platform, not the server platform
• use a compatible interpreter for its platform

In practice:

• Linux script alert rules use bash
• Windows script alert rules use powershell or cmd

The rule stores the value path, comparator, threshold, and severity. Ordyn sends the script and rule metadata to the endpoint as an alert-rule evaluation instruction.

The script must print valid JSON to stdout. The agent reads the configured value path from that JSON document, compares the observed value with the rule threshold, and returns the evaluated result to Ordyn.

For example, a script can output:

{
  "defender": {
    "signature_age_days": 5
  }
}

With the value path defender.signature_age_days, a number threshold of 3, and the comparator above, the agent records the rule as triggered.

The value path can also start with $., for example $.defender.signature_age_days. Array indexes are supported as path segments.

The agent sends Ordyn a result that includes:

{
  "triggered": true,
  "observed_value": 94,
  "threshold_value": 90,
  "severity": "critical",
  "message": "Memory usage is above threshold."
}

If the script exits with a non-zero code, prints invalid JSON, misses the configured value path, or returns a value with the wrong type for the rule, Ordyn records the rule state as error.

Assignments

Alert rules are assigned from scope action menus, not from inside the alert rule definition.

You can assign alert rules to:

• tenant
• endpoint folder
• endpoint group
• endpoint

This works like configuration profile assignments. An endpoint can receive alert rules directly and through inherited scopes.

The endpoint Alerts tab shows:

• every effective rule for the endpoint
• where the rule is applied from
• the latest state
• the latest observed value and threshold
• the latest message or error
• when the rule was last evaluated

Evaluation

Ordyn checks for due alert rule evaluations on its regular background schedule.

The alert-rule dispatcher only considers endpoints that are:

• approved
• agent endpoints
• currently connected through an active relay connection

Disconnected endpoints are skipped. This avoids raising alerts from stale endpoint data when the endpoint is not currently able to report fresh data.

Each rule has an evaluation interval in minutes. Ordyn skips a rule until the latest evaluation is older than that interval.

For script alert rules, Ordyn also skips dispatch when:

• the endpoint is busy
• another alert-rule evaluation instruction for the same endpoint and rule is already pending, queued, or issued
• the script platform does not match the endpoint platform

For built-in alert rules, Ordyn evaluates the rule from the latest current system status. Guard-related rules are skipped as incompatible when the endpoint reports that the feature is not compatible.

States

Each endpoint/rule pair has a current state:

• healthy - the rule evaluated successfully and did not trigger
• triggered - the rule evaluated successfully and triggered
• error - the rule could not be evaluated

Triggered alerts use the rule severity:

• warning
• critical

Rule errors do not use the rule severity. They are shown as rule errors because they mean the check itself needs attention.

Clearing alerts

Use Clear on the endpoint Alerts tab to acknowledge an active alert or alert-rule error.

Clearing does not delete the rule and does not disable future evaluation. It records who acknowledged the current state.

If the same triggered or error state is still present on the next evaluation, Ordyn preserves the acknowledgement. This means an acknowledged alert does not reappear on every check while the same problem is still accepted.

If a triggered result changes into an evaluation error, or an evaluation error changes into a triggered result, Ordyn removes the acknowledgement because the endpoint requires attention for a materially different condition. Changes to only the observed value, threshold, severity, or message do not remove the acknowledgement.

If the rule becomes healthy, Ordyn clears the acknowledgement with the resolved state. A future trigger is shown as a separate alert.

Alert automations

An event automation can run a job when one selected alert rule becomes active on an endpoint. Select Alert activated as the event and choose the alert rule.

The automation runs for a new transition into the triggered state. Repeated triggered evaluations, acknowledgement, evaluation errors, and resolution do not run it again. After the rule becomes healthy, a later trigger starts a new alert and can run the automation again.

Alert automations support the normal tenant, folder, group, and endpoint scopes. Existing automation ordering, jitter, job assignment, and endpoint disable behavior also apply.

Sidebar indicator

The endpoint sidebar shows an alert icon beside an endpoint name when the endpoint has unacknowledged alert attention.

The icon is shown for:

• active unacknowledged triggered alerts
• unacknowledged alert-rule errors

Alert-rule errors take visual priority over normal active alerts.

The sidebar state is loaded with the endpoint list and updated through realtime endpoint updates when alert states change or are cleared.

Dynamic groups

Alert state can be used in dynamic endpoint groups.

Available dynamic group fields are:

• Active unacknowledged alerts
• Unacknowledged alert rule errors
• Alert attention required

These fields only consider unacknowledged states.

Alert attention required matches when either an active alert or an alert-rule error exists.

When an alert state changes in a way that affects these fields, Ordyn refreshes dynamic group membership for the endpoint's tenant.

Operational notes

Alert rules depend on the telemetry they evaluate.

For built-in rules, make sure the endpoint reports current system status and security posture data. Missing telemetry is recorded as an alert-rule error.

For script rules, keep scripts small and reliable. Script alert rules run as normal endpoint instructions and can be skipped while the endpoint is busy.

Use built-in rules for common checks whenever possible. Use script rules when the required signal is not available in Ordyn's built-in system status or security posture data.