Anomaly detection configuration

• Latest Dynatrace
• Explanation
• 7-min read
• Updated on Apr 17, 2026

An anomaly detection configuration relies on several components:

Once configured and activated, the configuration observes the data and triggers an event when conditions are met. To ensure the configuration works as expected and alerts you about the right events, you can preview the results of its work:

Data source

Data source provides a time series that is evaluated by Dynatrace Intelligence:

If your data has a latency, you need to offset it in your configuration via the Query offset parameter. Specify the value in minutes.

Delay

The Delay parameter helps you to reduce the frequency of DQL query executions performed by a custom alert in an hour, thereby helping to lower query costs and minimize system load.

While the default delay period between custom alert executions is 1 Minute, you can configure the query execution to longer intervals (for example, every five minutes) without losing the ability to perform retroactive evaluations for each minute within the selected time window.

You can configure the Delay parameter using Minutes or Seconds, but the delay can't be longer than 60 Minutes.

Data type

The Data type parameter allows you to choose which type of data for which the Anomaly Detection configuration should create alerts.

Timeseries

Timeseries analyzers alert based on the detected threshold violations, like static threshold analyzer, and pattern deviations, like seasonal baseline. This means that timeseries analyzers raise an alert based on:

Timeseries analyzers are suitable for:

Analyzer type and parameters

Analyzer parameters define how Dynatrace Intelligence evaluates the data provided by the data source. The exact set of parameters depends on the type of the analysis:

Records

A records data type analyzer alerts based on the records that matches the filters provided in the Query parameter field. This means that each record detected by a custom alert with Data type set to Records is treated as a potential anomaly that should be reported.

A records-based analyzer is suitable for:

Alert identity fields

As we explained in the DQL writing guide, most record fields are treated as dimensions: every distinct value produces a separate monitored dimension. To prevent a rapid increase in monitored dimensions, remove volatile (high‑cardinality) fields from the query. However, those volatile fields often contain useful context you still want attached to the event. With Alert identity fields feature, you can keep volatile fields in the query for event context while selecting only stable fields for the anomaly detector. Unselected fields are ignored for monitoring purposes but remain in the event properties for context.

For this parameter, you should only provide fields with stable values that don't change over time. This helps you avoid duplicate events and reduces noise by matching newly detected records with the ones you've already been alerted on. If the identity fields match between the records, the existing event gets updated instead of creating a new one.

Missing data alert

Dynatrace provides you the ability to set an alert on missing data in a metric or a DQL query. If the alert is active, Dynatrace regularly checks whether the sliding window of the anomaly detection configuration contains any measurements. For example, if the sliding window is set to 3 violating samples during any 5 minutes, Dynatrace triggers an alert if there's no data within a 3-minute period.

The missing data condition and threshold condition are combined by the OR logic.

We recommend disabling missing data alerts for sparse data streams, where measurements are not expected in regular intervals, as it will result in alert storms.

For expected late-incoming data (for example, cloud integration metrics with a 5-minute delay), use long sliding windows that cover delays. For a 5-minute delay, use a sliding window of at least 10 minutes.

The {missing_data_samples} event description placeholder resolves to the number of minutes without data received.

Sliding window

The sliding window of an anomaly detection configuration defines how many one-minute samples must violate the threshold during a specific period. When the specified number of violations is reached, Dynatrace raises an event. The goal is to avoid overly aggressive alerting on single violations, when every measurement that violates the threshold triggers an event.

The event remains open until the metric stays within the threshold for a certain number of one-minute samples within the same sliding window, at which point Dynatrace closes the event. Keeping the event open helps to avoid over-alerting by adding new threshold violations to an existing problem instead of raising a new one.

You can find settings for the sliding window in the Advanced properties section of the configuration. By default:

You can set a sliding window of up to 60 minutes for each of the three analyzer types.

Let's consider a case of a static threshold of 90% CPU usage.

Explanation of the sliding window and de-alerting

The event analysis starts with the first violating sample in the sliding window. Once the number of violating samples reaches the defined threshold, the event analysis stops and a problem is raised. Even though event analysis is stopped, the event itself remains open until the de-alerting criteria are met:

Both criteria must be met to close the event.

The default numbers (3 violating samples in the sliding window of 5 samples to trigger a problem, 5 de-alerting samples to close the event) are a good fit for most configurations. However, you might need to update them (for example, due to noise in measurements).

Event template

The event template defines characteristics of an event triggered by threshold violation. You need to provide at least the name and the type of the event.

You can provide additional parameters as key-value pairs. For a list of possible event properties, see Semantic Dictionary.