Rules

Rules define what to watch and when to raise an Alert. Each rule targets one resource group (Directors, Devices, or Targets), picks one rule type, applies to a configurable scope of resources within that group, and runs on the engine's one-minute evaluation tick.

Accessing Rules

Navigate to Monitoring > Rules. The page lists every rule in the tenant — both user-created rules and system rules that ship with the platform.

Rules List

Columns:

Column	Description
Rule Name	Name assigned at creation
Resource Group	Directors / Devices / Targets
Rule Type	The chosen rule type (for example, Disk utilization)
Applied Resources	Number of resources currently in scope (or All)
Severity	Severity levels configured on the rule (one for single-severity rules, up to four for multi-severity rules)
Status	Active / Passive — Active rules are evaluated every minute; Passive rules are not

Controls:

• Search rules — free-text search across rule name and rule type
• Resources filter — All, Directors, Devices, Targets
• Rule Type filter — populated from the rule types available for the selected resource group
• Pagination at the foot of the table

Per-row actions (row menu): Manage rule, Clone rule, Enable rule / Disable rule, Delete rule.

The Create new rule button at the top right opens the creation wizard. The button is gated by the create-rule permission; users without that permission do not see it.

Creating a Rule

The wizard runs in four steps. The Next button is disabled until every required field on the current step is valid.

Define Rule Scope

Field	Description
Rule name	Required. Up to 255 characters.
Description	Optional. Free text.
Resource Group	Required. One of Directors, Devices, or Targets. Drives every option in the remaining steps.
Scope	Required. See the scope modes below.

Scope modes (labels follow the chosen resource group — directors, devices, or targets):

Mode	Behavior
All directors / All devices / All targets	The rule applies to every current and future resource in the chosen group. A Set up exceptions control below the selector excludes explicitly selected resources from the rule.
Selected directors / Selected devices / Selected targets	The rule applies only to the resources picked from the list.
All devices with specific directors	Device rules only. Pick one or more Directors; the rule applies to every Device connected to those Directors, including Devices added later.

Set Rule Type

Pick one rule type from the cards shown for the selected resource group. The set of available types depends on the resource group — see Rule types for the catalog.

Define Rule Behavior

The fields that appear in this step depend on the chosen rule type. The common controls are:

Control	Description
Custom working hours	Toggle. Off (default) means the rule is evaluated continuously. On lets the user add one or more windows of weekday + start/end time in a chosen timezone; outside those windows the rule is not evaluated.
Severity	Single-severity rule types fix one level (Critical, High, Medium, or Low). Multi-severity rule types accept up to four severity rows, each with its own threshold.
Threshold	The numeric trigger value for threshold-based rule types. For utilization rules the unit is fixed to percent and capped at 100; for data and event volume rules a unit selector accompanies the value, or, with the threshold type Change from the average, a percentage, or, with Anomaly detection, no threshold: a sensitivity and one severity — see Threshold type.
Time period	The observation window over which the engine evaluates the rule. Minimum one second. For status and no-data rules, it is how long the resource must stay silent before the rule fires — see Status and no-data rules.
Resolve condition	Available on the rule types marked yes in the Rule types tables. Do not resolve the alert (the default) keeps the alert open until manually resolved. Resolve alert after a time period sets a period after which the alert auto-resolves. Anomaly detection rules have Resolve alerts automatically instead; see Threshold type.

Review and Create Rule

A read-only summary of every value entered in the preceding steps. Create rule submits the rule; the wizard then redirects to the new rule's detail page.

Rule Types

The Rule Type filter in the list and the cards on the wizard's Set Rule Type step are populated from the catalog below. The Severity model column shows whether the rule type uses one fixed severity (single) or up to four severity rows with thresholds (multiple). The Threshold column shows the input fields shown on Define Rule Behavior — — means the rule type has no threshold value (it fires on a binary condition such as disconnection).

Director rules

Rule type	Severity model	Threshold	Resolve condition
Director status	single	—	yes
No data received	single	—	yes
Total ingest amount	multiple	value + unit (KB / MB / GB / TB / events)	—
Disk utilization	multiple	percent (≤ 100)	—
Processor utilization	multiple	percent (≤ 100)	—
Memory utilization	multiple	percent (≤ 100)	—
Queue usage	multiple	percent or size — see Queue usage input mode	yes
Crash detection	single	—	yes

Device rules

Rule type	Severity model	Threshold	Resolve condition
Device status	single	—	yes
No data received	single	—	yes
High data volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (KB / MB / GB / TB), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
Low data volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (KB / MB / GB / TB), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
High event volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (events), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
Low event volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (events), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)

Target rules

Rule type	Severity model	Threshold	Resolve condition
Target status	single	—	yes
High data volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (KB / MB / GB / TB), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
Low data volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (KB / MB / GB / TB), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
High event volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (events), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
Low event volume	multiple (anomaly detection: one, optionally raised to Critical)	value + unit (events), % change from the average, or anomaly detection — see Threshold type	— (anomaly detection: automatic, optional)
Queue usage	multiple	percent or size — see Queue usage input mode	yes
Backpressure	single	—	yes

Severity models

A single-severity rule has one severity level — the rule either fires at that level or not at all. Director status, Device status, Target status, No data received, Crash detection and Backpressure use this model.

A multi-severity rule accepts up to four severity rows. Each row pairs a severity (Critical, High, Medium, Low) with its own threshold; the wizard validates that the thresholds are ordered consistently — Critical at the highest impact, Low at the lowest. When an evaluation crosses more than one threshold simultaneously, the highest matching severity is used.

Queue usage input mode

Queue usage rules expose an extra control that selects between two threshold interpretations:

Mode	Threshold meaning
Percentage	Threshold is a percentage of queue capacity, capped at 100
Size	Threshold is an absolute size — value plus unit (KB / MB / GB / TB)

Switching mode replaces the threshold input field on the form.

Threshold type

The four volume rule types — High and Low data volume, High and Low event volume, on devices and on targets — can compare each time period with a fixed amount, with the resource's own average, or with what it normally carries at that hour of the week. On Define Rule Behavior, Select what the thresholds compare against offers three tiles:

Tile	Threshold meaning
A fixed amount	Default. Each severity row is an amount — value plus unit — that the volume in a time period must pass.
Change from the average	Each severity row is a percentage change from the resource's average, so one rule fits resources with different traffic.
Anomaly detection	Learns the resource's normal for every hour of the week and alerts when a time period is too far outside it. No severity rows: one sensitivity and one severity.

An amount and a percentage do not convert into each other, so switching tiles clears the severity rows' values. The anomaly detection settings keep their values.

The choice is not offered with source-level monitoring scope; choosing source-level takes the rule back to A fixed amount, from Change from the average and from Anomaly detection alike.

Anomaly detection is a new threshold type, not a rename: existing rules keep the type they were saved with. It is offered where the other two tiles are — the four volume rule types on devices and on targets, without source-level scope, under the monitoring.rules feature — and has no edition gate of its own.

Define the average. With Change from the average:

• Average of the last — 1 hour, 3 hours, 6 hours, 12 hours, 24 hours (the default), 2 days, 3 days, 5 days or 7 days. It must hold at least two time periods.
• Minimum average (optional) — a resource whose average is below this value is not evaluated. On a quiet resource a small change is a large percentage: 10 events becoming 30 is +200%. The value is in events for event volume rules, and in KB, MB, GB or TB for data volume rules.

The average is the resource's typical volume in one time period: the total over the lookback divided by the number of time periods in it. With a 5-minute time period and 7 days, the total of the last 7 days is divided by the 2,016 five-minute periods in it. Periods with no data count as zero. A resource that has reported for less than three quarters of the lookback is not evaluated yet, so a newly added device raises no alerts until it has enough history.

Split the average by working hours. Offered only when the average covers 3 days or more; choosing a shorter lookback clears the split.

• Working hours for the average — a schedule of its own, independent of the rule's Custom working hours, which still only decide when the rule runs.
• A time period inside these working hours is compared with the working-hours average, and one outside them with the off-hours average. A time period that crosses the start or end of working hours is not evaluated.
• Separate thresholds outside working hours — Off: time periods outside working hours are not evaluated, and the rule only alerts in working hours. On: they are compared with the off-hours average using a second set of severity rows, shown in two columns, In working hours and Outside working hours.

Severity rows. Each row takes a percentage:

Rule type	Row	Range
High data volume, High event volume	Increase over average	Above 0, at most 10,000. 50 means 50% more than the average; 100 means twice the average.
Low data volume, Low event volume	Decrease from average	Above 0, less than 100. 50 means half of the average; 90 means a tenth of it.

The review step and the Rule Configuration tab show the choice under Threshold Type, for example Change from the average of the last 7 days, split by working hours (Mon-Fri, 09:00 - 18:00), and list the off-hours rows under Thresholds Outside Working Hours. An alert from such a rule states the change and both amounts, for example Event count in the last 5m changed by -80.6% from its 7d average (194 events, average 1,000 events).

Learn the normal. With Anomaly detection, the severity rows are replaced by two blocks. The first, Learn the normal, has:

• Learn from the last — 2 weeks, 4 weeks (the default) or 8 weeks.
• Sensitivity — Sensitive: smaller departures alert, Balanced (the default) or Only extreme departures.

For every hour of the week — Monday 09:00, Monday 10:00 and so on — the normal is the median of that hour's time periods over the learning period, and the usual spread around it is learned too. The hours are read in the time zone of the user who sets up the rule; the block's description names it, and the rule keeps it once saved. Periods with no data count as zero. A resource is evaluated once it has two weeks of history.

The sensitivity is measured in the resource's own usual swing around its normal. On a steady resource, Sensitive alerts at about 20% away from normal, Balanced at about 30% and Only extreme at about 45%; a noisy resource needs a larger move for each. A rule set through the API with another score shows its sensitivity as Custom (score N).

Define alert severity. The second block takes:

• One severity — Critical, High (the default), Medium or Low.
• Raise to Critical when far outside the normal — on by default, and hidden when Critical is the severity. A time period half again as far outside its normal as the sensitivity allows is raised as Critical.
• Resolve alerts automatically — on by default. On: an alert closes once the resource has been back within its normal for 10 minutes, or for one time period if that is longer, and a new anomaly opens a new alert. Off: alerts stay open until someone resolves them.

Some noise controls are built in and have no fields:

• A departure must last 3 minutes before it alerts.
• A change smaller than a tenth of the resource's busiest hour is ignored, so a few extra events on a quiet night do not alert.
• A time period in which all the resources evaluated together sent nothing is read as an ingestion outage and not evaluated, so an outage neither raises nor resolves alerts.

The Time period has limits of its own in this mode, each with its own error under the field:

• at least 1 minute and at most 1 hour;
• it must divide an hour evenly, for example 5m, 15m or 30m;
• a 1-hour time period needs a learning period of 4 weeks or more.

The review step and the Rule Configuration tab show the choice under Threshold Type, for example Anomaly detection, learned from the last 4 weeks (Europe/Istanbul), Balanced, with Alert Severity High, raised to Critical when far outside the normal and Resolve Automatically, once traffic is back to normal (or Manually). An alert from such a rule names the hour, its normal and the range it left, for example Event count in the last 5m is unusually low for Thursday 19:00 (Europe/Istanbul): 700 events, where this hour is normally 2,500 events (1,375 events to 3,625 events at this severity, learned over 4w).

Resolve condition

The rule types marked yes in the Rule types tables expose a resolve condition. The two options are:

• Do not resolve the alert — the alert stays Open until an operator resolves it manually.
• Resolve alert after a time period — the engine auto-resolves the alert once the configured time has passed since it first triggered, whether or not the condition still holds. If it still holds, the next evaluation opens a new alert.

The utilization, data-volume, event-volume and total-ingest rule types do not take a resolve condition, and their alerts never close on their own, unless a volume rule uses Anomaly detection with Resolve alerts automatically on — see Alerts.

Only an anomaly detection rule with Resolve alerts automatically on closes an alert because its condition has cleared — see Threshold type. A Director that reconnects leaves its Director status alert Open until the resolve period passes or someone resolves it. The built-in status and no-data rules use Do not resolve the alert, so their alerts stay Open until resolved by hand.

Rule Detail

Clicking a row opens the rule detail page, organized into five tabs — Rule Overview, Rule Configuration, Rule Actions, Triggered Alerts and Activity Logs. Editing on the detail tabs is gated by the settings-edit permission, which is distinct from the rule permissions that govern the list actions.

Rule Overview

The Overview tab summarizes the rule. A small set of fields is editable inline:

• Rule Name
• Description
• Assigned Resources — the scope; the displayed count includes a See all link that lists the resources currently matched

The following fields are immutable after creation:

• Rule Type
• Resource Type

Rule Configuration

Every behavior field from the wizard's Define Rule Behavior step is editable here — working hours, threshold type, average settings and anomaly detection settings, severity rows and thresholds, time period, queue usage input mode, and resolve condition. Saving changes applies them on the next evaluation tick.

Rule Actions

The notifications this rule sends when it fires. The tab lists the assigned actions by Action Name, Action Type and the Severities each one answers to; Manage rule actions switches it into edit mode, where Add new action opens a three-step picker — choose the action type, select an existing configured action, then set its details.

Six action types exist: Email, Slack, SMS, Jira, Freshservice and Freshdesk. Each is chosen from actions already configured on the platform rather than defined here — see Rule Actions — and this tab assigns them to the rule.

The details step is where the assignment is shaped. Every type asks which severities trigger it — a severity the rule itself does not define cannot be selected. Beyond that, Email and SMS collect recipients, Slack and SMS take a message template, and Jira takes a default assignee, labels and a policy for what happens when the same alert fires again, so a flapping rule does not open duplicate tickets. Freshservice and Freshdesk take a priority, an optional group and agent, tags, the same repeat policy (open a new ticket, or add a private note to the existing one), and the ticket's subject and description.

A rule with no actions assigned still evaluates and still raises alerts — it just notifies nobody.

Triggered Alerts

A table of alerts the rule has produced, with pagination at the foot — the tab has no search or filter controls.

Column	Description
Last Updated	Most recent change
Severity	Current severity
Trigger Condition	Threshold and current value snapshot
Resource	Resource that produced the alert
Status	Open / Acknowledged / Resolved

Activity Logs

The rule's activity: the changes made to it, and the outcome of every notification its actions were due to send. The same rows appear on the Audit page under object type AlertRule.

A notification is recorded once its outcome is final (for one that was sent, after the sender's retries) as one of three actions:

Action	Meaning
RuleActionNotificationDelivered	Every recipient was reached.
RuleActionNotificationFailed	At least one recipient was not reached. A partial delivery counts as failed, and the description says how many were missed: Rule action "Ops mail" could not reach 1 of 2 recipients: …
RuleActionNotificationNotSent	No recipient was tried: a quota stopped it, or the action was detached, deleted or disabled before its notification went out.

These rows show System in the User column, not a person: the platform wrote them, so there is no user profile to open.

A grouped notification, one covering several alerts, is recorded as one row. When it is delivered, its description says how many alerts it covered; whatever its outcome, the details give the count under Alerts.

The action dropdown above the table filters the rows by action. Clicking a row's action opens its details. For a notification, these are:

Label	Shows
Reason	Why the first recipient not reached was missed
Error code	The error code for that recipient
Attempts	How many attempts the sender made
Recipients	Each recipient with its outcome, for example _ops@company.com: failed (550 mailbox unavailable)_
Provider reference	The provider's reference for what it created: a Jira issue key, a Freshservice or Freshdesk ticket
Rule action, Rule action type, Rule action ID	The rule action that sent it
Rule ID, Rule name, Assignment ID	The rule and the action's assignment to it
Alert IDs, Alerts	The alerts the notification covered, and their count
Resources, Resource type	The resources the alerts were raised on
Severity, Event	The alert's severity and the event that triggered the notification
Notification group ID	The group, for a grouped notification

Alert IDs and Resources list the first 100 entries; Alerts is always the full count.

Rule Actions

Action	Effect
Manage rule	Opens the rule detail page. Available from the rules list row menu only.
Clone rule	Creates a draft copy of the rule and opens it in the wizard at Define Rule Scope, including for system rules that cannot be edited directly.
Enable rule / Disable rule	Toggles status between Active and Passive. A Passive rule is preserved but is not evaluated.
Delete rule	Removes the rule and stops further evaluation. Existing alerts that the rule produced remain in the alerts list.
Export template	Opens the rule as a Bicep template, with Open in Deploy, Download and Copy. Available from the rule detail header only. See Deploy.

Apart from Manage rule and Export template, all actions are available both from the rules list row menu and from the rule detail header.

System rules

System rules are shipped with the platform. They are marked in the rules list and behave like user-created rules at evaluation time, but they cannot be edited or deleted. Clone rule is available — use it to produce a customizable copy that can then be edited like any other rule.