Anomaly detection alerts

Anomaly detection alerts catch metric behavior that drifts from its normal pattern, without you setting a fixed threshold. Use them when a meaningful level changes over time, for example, when a transaction's response time climbs above what is typical for that hour or a host's outbound traffic exceeds its usual range.

Coralogix learns the expected behavior of each metric series from recent history and triggers when live values deviate from that baseline. These alerts evaluate streaming metrics in real time, without prior indexing.

What you need

• Access to Coralogix with permission to create alerts
• A metric with enough history to build a reliable baseline (see Data requirements)

Build an anomaly alert

To create an anomaly detection alert, go to Alerts, then select Create alert. The alert creation wizard opens on the Query step. The Anomaly type uses the same four-step flow as every alert (Query, then Condition, then Notification, then Details); the parts below are specific to anomaly detection.

Query: define the metric signal

1. On the Query step, select the Anomaly alert type.
2. Define the metric series to model. Switch between Builder and Query to construct a PromQL expression, group by labels, and preview the result series.

The series your query defines, including its grouping, is what Coralogix learns a baseline for. Each combination of group-by label values is modeled separately.

Condition: deviation from the baseline

On the Condition step, set the direction of the deviation that should trigger the alert:

• More than usual: fire when the metric rises significantly above its learned baseline.
• Less than usual: fire when the metric drops significantly below its learned baseline.

Tune how far a value must deviate before the alert fires with the deviation percentage. See Anomaly sensitivity for how this setting maps to detection behavior. To absorb late-arriving metric data, add a custom evaluation delay.

For the Notification and Details steps, including routing, cadence, naming, and labels, see Configuring an alert definition.

Data requirements

Anomaly detection needs enough historical data to establish a reliable baseline.

• The model trains on the previous 7 days of metric data.
• At least 90% of this 7-day period must contain data.
• This requirement applies to the training window, not the alert evaluation window.

If this requirement is not met, no baseline is created and anomaly detection does not run.

When the alert becomes active

The 7-day requirement applies to the metric history, not the alert age. If the metric already has more than 7 days of history when you create the alert, the alert becomes active within approximately 24 hours, after the next daily model build. You do not need to wait 7 days from alert creation.

If the metric has less than 7 days of history at creation time, the alert becomes active once 7 days of history accumulate.

Changes that trigger a new learning period

Some edits to an alert definition retrain the model, which restarts the 7-day learning period and temporarily disables the alert. Others do not affect the model.

Changes that trigger a new learning period:

• Creating a new anomaly detection alert
• Changing the metric query, filter, or PromQL expression
• Changing core condition logic that defines the time series being modeled

Changes that do not trigger a new learning period:

• Changing the deviation percentage or sensitivity
• Changing notification settings, labels, or suppression rules
• Changing the alert name or priority

Limitations

• The baseline is rebuilt daily and applied for the following 24 hours.
• The model uses data from the past 7 days.
• A maximum of 500 permutations per metric is supported.

Related resources

Next steps

Set up custom webhook notifications for your metric alerts in Custom webhooks: metric alerts.