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	Enabled / Disabled — Enabled rules are evaluated every minute; Disabled 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
• Status filter — All, Enabled, Disabled. It filters the whole list, not only the page on screen, and choosing a status goes back to page 1. It does not reset the other two filters, and they do not reset it.
• 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. The rule types that judge each resource by its own history, such as Event storm or how fast it is filling up (Forecast rules), are listed under their own Anomaly detection heading.

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. Not offered for a gradual decline rule, which judges whole days — see Gradual decline — or for a forecast rule, which always reads the last hour — see Forecast rules.
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 an event storm rule it is whole minutes from 1m to 15m — see Event storm. A gradual decline rule has no time period field: it always judges the last 7 days — see Gradual decline. Nor does a forecast rule: it always reads the last hour — see Forecast rules. 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. Resolve the alert when the resource is back to normal closes the alert once the resource has been back to normal for 10 minutes. Not every rule type offers all three; see Resolve condition. Anomaly detection rules have Resolve alerts automatically instead; see Threshold type. So do event storm, gradual decline and forecast rules; see Event storm, Gradual decline and Forecast rules.

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). The Resolve condition column shows which choices the rule type offers: yes means all three — see Resolve condition.

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)	yes, without a time period
Processor utilization	multiple	percent (≤ 100)	yes, without a time period
Memory utilization	multiple	percent (≤ 100)	yes, without a time period
Queue usage	multiple	percent or size — see Queue usage input mode	yes
Crash detection	single	—	yes, without back to normal
Event storm	single, optionally raised to Critical	a sensitivity (a multiple of the usual) — see Event storm	automatic, optional
Gradual decline	single, optionally raised to Critical	a sensitivity (a percentage lower) — see Gradual decline	automatic, optional
Queue filling up	single, optionally raised to Critical	hours before the limit (1 / 6 / 24) — see Forecast rules	automatic, optional
Disk filling up	single, optionally raised to Critical	hours before the limit (1 / 6 / 24) — see Forecast rules	automatic, optional

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)
Event storm	single, optionally raised to Critical	a sensitivity (a multiple of the usual) — see Event storm	automatic, optional
Gradual decline	single, optionally raised to Critical	a sensitivity (a percentage lower) — see Gradual decline	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
Event storm	single, optionally raised to Critical	a sensitivity (a multiple of the usual) — see Event storm	automatic, optional
Gradual decline	single, optionally raised to Critical	a sensitivity (a percentage lower) — see Gradual decline	automatic, optional
Delivery falling behind	single, optionally raised to Critical	lag limit (15 min / 1 h / 6 h) and hours before it (1 / 6 / 24) — see Forecast rules	automatic, optional

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.

With source-level monitoring scope, Change from the average is not offered; choosing source-level takes a rule that uses it back to A fixed amount. A fixed amount and Anomaly detection are both offered.

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, 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.

With source-level monitoring scope, each log source of the selected devices learns its own normal, and the rule alerts for each source separately. A High rule catches a single source that rises above its normal, and a Low rule one that falls below it, even when its device's total looks normal. The alert is raised on the log source, as with a source-level rule that uses a fixed amount, and resolves per source. Two limits apply. The Time period must be at least 15 minutes. A rule can watch up to 1,000 log sources: a rule that would watch more is refused when it is saved, with a message that says how many sources it would watch. If the devices find more sources after the rule is saved, the rule watches the 1,000 busiest. The sources counted are those of the devices in the rule's scope, minus the ones the rule leaves out, or only the ones it names with Selected log sources; sources of deleted devices are not counted.

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;
• with source-level monitoring scope, at least 15 minutes instead of 1 minute. The field shows With anomaly detection per log source, the time period must be at least 15 minutes. When anomaly detection is picked at source level, or an anomaly detection rule is switched to source level, a shorter time period is raised to 15 minutes by itself.

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).

Event storm

An Event storm rule alerts when a resource's events suddenly multiply. It is offered for Directors, Devices and Targets, under the Anomaly detection heading of Set Rule Type, and watches:

• the events a Director receives, from one Device or spread over many;
• the events a Device sends;
• the events a Target is sent, for example when a pipeline stops filtering.

Each time period is compared with the resource's own last 3 hours. A time period is a storm when all three of these hold:

• It carries more than the sensitivity's multiple of the usual time period. The usual time period is the median of the last 3 hours, so a few busy periods do not move it.
• It carries at least a tenth more than the busiest time period in those 3 hours, so an hourly batch job is not a storm.
• It adds at least 10 events a second over the usual.

On Define Rule Behavior, the rule takes:

• Sensitivity — Sensitive: 3 times the usual, Balanced: 5 times the usual or Only extreme: 10 times the usual. Balanced is the default on Devices and Targets, and Sensitive on Directors. A rule set through the API can use any multiple from 2 to 100, and the console shows it as Custom: N times the usual.
• One severity, and Raise to Critical when far above the usual — on by default. A time period at twice the sensitivity's multiple (10 times the usual with Balanced) is raised as Critical.
• Resolve alerts automatically — on by default. On: an alert closes once traffic has been back to normal for 10 minutes, or for one time period if that is longer. Off: alerts stay open until someone resolves them.
• Time period — whole minutes from 1m to 15m, 1m by default. The engine judges the minutes that have just ended.

Some behaviour is built in and has no fields:

• An alert is raised once a resource has stayed in a storm for 2 minutes.
• The minutes of earlier storm alerts are left out of the last 3 hours. A storm never becomes the usual, and a second, smaller storm still alerts.
• A resource is judged only once it has reported for at least three quarters of the last 3 hours, and it needs at least 12 reference time periods outside earlier storms. A newly added resource raises no storm alerts until then.

Rule lists and detail pages show the rule type as Event storm · Anomaly detection. Volume rules that use Anomaly detection carry the same marker. An alert explains itself in its trigger condition, for example Event count in the last 1m is 12 times its usual: 8,400 events, where it usually carries 700 events (its busiest 1m in the last 3h carried 700 events).

Gradual decline

A Gradual decline rule alerts when a resource sends fewer events week after week, too slowly for any single time period to cross a threshold. It is offered for Directors, Devices and Targets, under the Anomaly detection heading of Set Rule Type, beside Event storm. It counts events, not bytes:

• the events a Director receives;
• the events a Device sends;
• the events a Target is sent.

Once a day, after midnight UTC, the engine compares the resource's events per day over the last 7 completed days with its events per day 15 to 28 days ago. The days are whole days in UTC. A resource is in decline when all three of these hold:

• Its last 7 days are lower than 15 to 28 days ago by at least the sensitivity's percentage.
• Its last 3 days are lower by at least that percentage too, so a resource that has recovered from an outage does not alert.
• It loses at least 1,000 events a day. This floor has no setting.

Each day is compared with the same weekday 15 to 28 days ago, so a quiet weekend is no decline. The week between the two sides is left out, so a slow slide has time to show.

On Define Rule Behavior, the rule takes:

• Sensitivity — Sensitive: 20% lower, Balanced: 30% lower (the default) or Only extreme: 50% lower. A rule set through the API can use any percentage from 5 to 95, and the console shows it as Custom: N% lower.
• One severity, and Raise to Critical when far below its weeks before — on by default. A week one and a half times the sensitivity's percentage lower (45% lower with Balanced) is raised as Critical.
• Resolve alerts automatically — on by default. On: an alert closes once the last 3 days are lower by less than half the sensitivity's percentage (under 15% lower with Balanced). Off: alerts stay open until someone resolves them.

The rule has no Time period field, because it always judges the last 7 days, and no Custom working hours, because it judges whole days.

Some behaviour is built in and has no fields:

• While an alert is open, the resource is compared with the days the alert was raised against, not with a moving reference. A loss that lasts never becomes the new normal and never closes the alert by itself. The alert's severity only goes up.
• When someone resolves an alert by hand, the resource's new level becomes its normal, and the alert does not reopen. The resource is judged again once the days 15 to 28 ago hold enough days at the new level, after about 3.5 weeks.
• When the rule has history for more than one resource, a day on which every one of them was silent is left out.
• Cold start: a resource with no data in the first half week of the reference (days 25 to 28 ago) is not judged yet. A newly added resource raises no decline alerts until then.

Rule lists and detail pages show the rule type as Gradual decline · Anomaly detection. An alert explains itself in its trigger condition, for example Events per day are 37.6% lower than 15 to 28 days ago. The last 7 days carried 687,658 events a day, against 1,102,673 events a day then.

Forecast rules

Three rule types warn before something reaches its limit, at the rate it grew over the last hour. They are offered under the Anomaly detection heading of Set Rule Type:

Rule type	Resource group	Warns before
Queue filling up	Directors	one of the director's queues is full. A full pipeline queue drops its oldest data.
Disk filling up	Directors	a disk, or the message store when it has a limit, is full
Delivery falling behind	Targets	delivery to the target falls further behind than you allow

On Define Rule Behavior, the rule takes:

• Delivery lag limit — Delivery falling behind only: 15 minutes, 1 hour (the default) or 6 hours. Choose how late data can reach the target before it causes a problem.
• Alert when it will be full within, or Alert when it will pass the limit within for Delivery falling behind — 1 hour, 6 hours (the default) or 24 hours.
• One severity, and Raise to Critical when it will be full within an hour, or Raise to Critical when the limit will be passed within an hour for Delivery falling behind. The option is hidden when the warning is 1 hour or the severity is Critical.
• Resolve alerts automatically — on by default. On: an alert closes once nothing has been forecast to reach its limit within the warning for 10 minutes. Off: alerts stay open until someone resolves them.

The rule has no Time period field and no Custom working hours: it always reads the last hour.

How the forecast works:

• Every minute, the rule reads the last hour of the director's readings. For queues and disks, these are the space used and the limit. For a target, they are how far behind delivery is.
• It works out how fast each one is growing, and how many hours are left before it reaches its limit at that rate. A queue that drains and refills, or a single spike, barely changes the result.
• It needs at least 15 minutes of readings. Growth of less than half a percent of the limit in the last hour does not count. For delivery lag, a lag under 1% of the limit does not count either, so a healthy target's lag of a few hundred milliseconds never alerts.
• Each director or target gets one alert, naming the item that reaches its limit first. The alert is raised once the forecast has held for 3 minutes.

An alert explains itself in its trigger condition, for example:

• The sending queue will be full in about 2h 53m: 364 MB of 1 GB used (36%), growing 228.4 MB an hour. Once it is full, the director drops its oldest data.
• Disk /data will be full in about 13h 25m: 73.2 GB of 100 GB used (73%), growing 2 GB an hour.
• Delivery will be more than 1h behind in about 2h 54m. It is 17m behind now and falls 15m further behind every hour.

Resolve condition

The rule types marked yes in the Rule types tables expose a resolve condition. The three 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.
• Resolve the alert when the resource is back to normal — the alert closes itself once the resource has been back to normal for 10 minutes in a row. The 10 minutes are fixed and cannot be changed. A breach in between starts the 10 minutes over. If the problem returns after the alert closed, a new alert opens. The review step and the Rule Configuration tab show the choice as The alert closes automatically once the resource has been back to normal for 10 minutes.

Director status, Device status, Target status, No data received (on a Director or a Device, including a device rule that watches each log source), Queue usage (on a Director or a Target), Delivery lag and Backpressure offer all three options. Disk, Processor and Memory utilization offer Do not resolve the alert and Resolve the alert when the resource is back to normal, but no time period. Crash detection offers Do not resolve the alert and Resolve alert after a time period, but not back to normal.

What back to normal means depends on the rule type:

• Director, Device and Target status: the resource is connected.
• No data received: the resource sent data within the rule's Time period.
• Threshold rules (utilization, Queue usage and Delivery lag): the value is back under every threshold of the rule.
• Backpressure: the target reports no backpressure.

With this option, missing data never closes an alert. A query that failed, a Director that stopped reporting, or a resource with no data in the window leaves the alert open.

With this option, an idle resource's alert stays open. A target or queue with no traffic writes no readings, so a Queue usage, Delivery lag or Backpressure alert of an idle target stays open until traffic resumes or someone resolves it. The same applies to an idle Director pipeline queue in size mode.

An alert closed this way gets the resolution note This alert was automatically resolved by the system because the triggering condition is no longer met., and its timeline row reads Alert has been auto-resolved as the condition cleared — the same as an anomaly detection rule's. See Alerts.

In deployment templates and the public API, the choice is resolveCondition: { "type": "condition" }, with no afterSeconds. A time period stays { "type": "auto", "afterSeconds": N }.

The 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. The utilization rule types close their alerts on their own only with Resolve the alert when the resource is back to normal.

A rule with Resolve the alert when the resource is back to normal closes an alert because its condition has cleared. So does a volume rule using Anomaly detection, an event storm rule, a gradual decline rule or a forecast rule with Resolve alerts automatically on — see Threshold type, Event storm, Gradual decline and Forecast rules. With either of the other two options, a Director that reconnects leaves its Director status alert Open until the resolve period passes or someone resolves it. The built-in status, no-data, utilization, queue usage, backpressure and delivery lag rules use Resolve the alert when the resource is back to normal, so their alerts close once the resource is back to normal.

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.

Seven action types exist: Email, Slack, Microsoft Teams, 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, Microsoft Teams 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 keep the existing one up to date with private notes), and the ticket's subject and description. The message templates, subjects, summaries and descriptions can use message variables, such as the tenant name or a link to the alert.

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	Turns the rule on or off. A disabled rule is kept 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.

LogChain check failed is a device rule that every tenant gets as a system rule. It fires when a Director finds data from an agent that failed the LogChain check, isn't signed, or is missing from the agent's sequence, or when the Director refuses files. The alert names the agent and the table. It has no threshold, and it stays open until a person resolves it. A new failure after the alert was acknowledged opens it again. See LogChain.