Alerting

Agent Management detects problems from metric values, KPI values, and Agent Review outcomes. Use alert configurations to define which agents to monitor, what condition triggers an alert, how it closes, and where to report it.

An alert configuration defines a rule. An alert occurrence records an incident detected by that rule for an agent. A reporter sends a notification or creates an external record for an occurrence.

For example, a configuration monitors hourly latency for production agents. When one agent breaches its threshold, Agent Management creates an occurrence for that agent.

Alerting targets

The Applies to setting selects the agents monitored by a configuration:

Target	Applies to	Example
Universal	Every agent that supports the selected metric, including agents added later. Creating a universal configuration requires instance administrator access.	Monitor interaction error rate across all supported agents.
Platform	Applicable agents on one selected platform.	Monitor latency for agents on a production platform.
Scope	Applicable agents matching the selected scope’s criteria.	Monitor agents belonging to a customer-support scope.
Agent	One selected agent.	Monitor a customer-facing agent with a stricter latency rule.

Configurations at different targets are independent and combine. An agent configuration does not override a platform, scope, or universal configuration. An agent matching several configurations can produce separate occurrences for those configurations.

For example, an agent can have both a universal error-rate rule and an agent-specific latency rule. Both are evaluated. Two rules for the same metric also remain independent.

Each configuration evaluates the selected metric separately for each applicable agent. A universal cost configuration does not sum costs across all agents. Targets select the agents being monitored; reporters select notification destinations.

Metric trigger conditions

Select a metric, its evaluation period, and a detection method. Available metrics depend on platform capabilities and configured collection. They can include uptime, errors, latency, activity, tokens, cost, and KPIs. A KPI definition alone does not create an alert configuration.

The following examples use illustrative thresholds, not recommended defaults.

Immediate threshold

Evaluate a metric bucket against a warning or critical boundary. Choose At or above when high values indicate a problem, or At or below when low values indicate a problem. Equality breaches the boundary. Thresholds use the metric’s displayed unit. Leave a threshold empty to disable that severity.

For example, configure hourly interaction error rate with a warning threshold of 5% and a critical threshold of 10%, using At or above. A value of 5% breaches the warning boundary; a value of 10% breaches the critical boundary.

For uptime, use At or below instead. A value of 99% breaches an uptime threshold of 99%.

Sustained threshold

Require consecutive buckets to breach a threshold before opening or escalating an occurrence. Warning and critical severities have separate breach counts.

For example, require average latency to remain at or above 2,000 ms for three consecutive hourly buckets. Values of 2,100, 2,200, and 2,050 ms meet the condition. Values of 2,100, 1,900, and 2,050 ms do not form three consecutive breaches.

Rolling threshold

Compare a calculated value over a recent period with a warning or critical boundary. Configure the number of buckets and the calculation supported by the selected metric.

For example, compare the average over the latest three hourly latency buckets with a warning threshold of 2,000 ms. This evaluates the period’s calculated value; it does not require every bucket to breach 2,000 ms.

Baseline deviation

Compare a recent period with the preceding baseline period, using the same calculation for both. Configure the baseline and recent-period lengths, the change direction (Increase, Decrease, or Increase or decrease), and warning or critical percentage changes.

For example, compare average latency over the latest three completed hourly buckets with the preceding seven hourly buckets. If the baseline is 1,000 ms and the recent value is 1,200 ms, the increase is 20%. An increase threshold of 20% is breached.

These thresholds represent relative percentage changes. A percentage metric changing from 50% to 60% increases by 20% relative to its baseline, or 10 percentage points.

Evaluation timing and data

A bucket is the time interval over which a metric is calculated. The configuration’s granularity determines the bucket length. By default, metric configurations evaluate completed buckets. Include current bucket also includes the ongoing bucket, whose value can change as data arrives.

Evaluation scheduling, timezone, and collection delay affect when values become available. Rolling and baseline conditions require enough historical data for their configured periods. Repeatedly refreshing a chart does not create additional buckets or establish consecutive breaches.

An unavailable evaluation is not a healthy result. Review the agent Activity tab for collection problems before interpreting missing or stale values. See Monitoring for metric sources and collection health.

Agent Review trigger conditions

An agent configuration can monitor a linked Agent Review instead of a metric. Configure the required number of consecutive completed runs with errors. Run errors and test results with FAIL, CONFLICT, or EMPTY status count as failures; PASS and SKIPPED results do not.

For example, require two consecutive failed runs. One failed run followed by a healthy run does not meet the condition. Two consecutive failed runs do.

Missing or unreadable reviews are handled separately and can trigger an alert immediately rather than waiting for the configured failed-run count. A review with no completed run data does not establish a healthy or failed-run sequence.

Recovery, acknowledgement, and closure

Recovery means the observed condition returns to an acceptable state. Acknowledgement records that a user has seen the occurrence; it does not resolve the underlying problem. Closure ends the occurrence.

Metric configurations support these closure modes:

• When healthy again: close when the configured condition becomes healthy.

• After consecutive healthy evaluations: require a configured number of consecutive healthy evaluations. A breach or unavailable evaluation resets the healthy sequence.

• Beyond a recovery threshold (hysteresis): for immediate and sustained thresholds, use a separate boundary to avoid repeatedly opening and closing around the trigger value.

• Manual closure only: keep the occurrence open until a user closes it.

For example, trigger a latency alert at or above 2,000 ms and set its recovery threshold to 1,500 ms. The value must fall strictly below 1,500 ms to satisfy recovery; equality does not close the occurrence.

Enable Require acknowledgement before automatic closure when a user must acknowledge the occurrence before it closes automatically. Acknowledgement and recovery can happen in either order. Users with write access can also close an open occurrence manually. After manual closure during an ongoing problem, a healthy observation is required before another occurrence can open.

Agent Review configurations support closure when healthy again or manual closure only. A healthy completed review run satisfies recovery for automatic closure.

Reporters and notifications

Reporters deliver alerts through email, ServiceNow, or webhooks. A configuration can reference reusable global reporters or define its own reporters. Available destinations depend on configured integrations and permissions.

Automatic reporters run through the alerting workflow. Manual reporters provide an action that a user invokes for an occurrence. Group notifications groups notifications where the reporter supports it; webhook reporters do not support grouping.

For example, a scope configuration monitors customer-support agents and uses an automatic email reporter for the operations team. A manual ServiceNow reporter lets a user create an incident after investigating an occurrence.

Creating an occurrence does not guarantee successful notification delivery. Check reporting activity for delivery errors. Configure and test the destination before relying on external notifications.

Reviewing and managing alerts

The portfolio Alerting view provides Alerts and Configurations. Users with the required management permissions also have access to Reporters and reporting Activity. Agent and platform views provide alerts for their respective agents.

Review open occurrences that need attention, acknowledge occurrences under investigation, and consult closed occurrences for past incidents. Occurrence details provide the metric or review evidence, severity, configuration, and history. Use the associated metric chart and agent Activity to distinguish agent behaviour from source-data delay or collection problems.

Configurations can be edited, duplicated, enabled, disabled, or deleted subject to permissions for their target. Review the target and reporters when duplicating a configuration. Associated risk mitigations are managed from the agent risk assessment; see Risk management.

Agent Management also supports AI-generated alerts. These are distinct from the metric and Agent Review rules described here. See Dataiku AI in Agent Management for the related capabilities and setup.