---
title: Anomaly Detection for Data Observability Monitors
description: >-
  Understand how the anomaly detection model works for Data Observability
  monitors, including training, model states, seasonality, and metric-specific
  behaviors.
breadcrumbs: >-
  Docs > Data Observability Overview > Quality Monitoring > Guides > Anomaly
  Detection for Data Observability Monitors
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Anomaly Detection for Data Observability Monitors

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

**Note**: This page applies to anomaly-based Data Observability monitors only. If your monitor uses the **Threshold** detection method, this content does not apply.

## Overview{% #overview %}

By default, [Data Observability monitors](https://docs.datadoghq.com/monitors/types/data_observability.md) use an anomaly detection model tailored to common patterns in data quality metrics such as table freshness and row count.

The model learns from the metric's history to set expected bounds. When an observed value falls outside those bounds, the monitor triggers an alert.

## Training period{% #training-period %}

When you create an anomaly detection monitor, it enters a training period. During training, the monitor collects historical values to learn the metric's baseline behavior. It does not trigger alerts during this period, and the monitor chart appears in blue.

Training typically takes between 3 and 9 days. Because many data pipelines behave differently on weekends, the model needs to observe both weekday and weekend behavior.

After training completes, the monitor can alert. The chart shows the observed values over time, with bounds above and below the line as a shaded area showing expected values. The color shows the current state:

| Color | State    | Description                                                         |
| ----- | -------- | ------------------------------------------------------------------- |
| Blue  | Training | The monitor is learning baseline behavior. No alerts are triggered. |
| Green | Normal   | The observed value is within expected bounds.                       |
| Red   | Alerting | The observed value fell outside expected bounds.                    |

## Alert state{% #alert-state %}

When an anomaly is found, the model will remain in alert state for some time, until either the observed value returns to the original expected bounds or the anomaly has persisted long enough that the model considers it a new normal state. To resolve the monitor manually and return it to normal state, use [annotations](https://docs.datadoghq.com/monitors/types/data_observability.md#annotate-bounds).

## Metric-specific behavior{% #metric-specific-behavior %}

The model works differently for different metrics:

### Freshness{% #freshness %}

Freshness monitors alert when the time since the last refresh is longer than expected based on historical update patterns. The model adds a small buffer to the upper bound to avoid alerting on minor delays.

### Row count{% #row-count %}

Row count monitors alert not only when there is an unusual change, but also when a row count flatlines, meaning it has not changed for longer than normal. A stalled row count may indicate a broken pipeline.

### Percentage (e.g. nullness, uniqueness){% #percentage-eg-nullness-uniqueness %}

Percentage metrics are scaled from 0 to 100. If the metric has never been 0 or 100, a change to these values triggers an alert.

### Custom SQL{% #custom-sql %}

For Custom SQL monitors, select a model type for your metric: **Freshness**, **Percentage** or **Default**. The **Default** model infers the range from the metric's history. For example, if a custom metric has never returned a negative value, the model constrains the lower bound to 0.

## Seasonality{% #seasonality %}

The model adjusts for seasonal patterns, trends, and past annotations. For example, if a metric consistently drops on Sundays, the model treats lower values on Sundays as normal rather than anomalous.

The model detects the following seasonal patterns. The amount of history it uses depends on the pattern:

| Pattern      | Description                                                                              | History used            |
| ------------ | ---------------------------------------------------------------------------------------- | ----------------------- |
| Hour of day  | Metrics that follow intraday patterns, such as higher row counts during business hours.  | About the last month    |
| Hour of week | Metrics with consistent patterns across a full week at hourly granularity.               | About the last 3 months |
| Day of week  | Metrics that differ across days of the week, such as lower activity on Sundays.          | About the last 3 months |
| Day of month | Metrics with recurring patterns tied to the calendar month, such as end-of-month spikes. | Up to 400 days          |

Not all seasonal patterns are available for all metric types. The model requires at least two complete cycles of normal history to detect a pattern, and typically detects it after three or more cycles. For example, a weekly pattern needs at least two weeks of history, and the model usually detects it after three weeks.

## Trends{% #trends %}

The model accounts for whether a metric is growing or shrinking over time. For a metric that consistently adds rows each week, the model adjusts expectations based on the direction and rate of change rather than treating growth as anomalous.

## Annotations{% #annotations %}

Annotations let you immediately retrain the model when it misclassifies a point, either by missing an alert or by generating a false alert. Because data quality expectations are often metric-specific, annotations are the primary way to tune the model to your team's needs.

Annotations have two effects:

- **Correcting the current state**: Marking a flagged point as expected moves the monitor out of the alerting state to normal state at the next observation, so it can then alert on new anomalies.
- **Shaping future predictions**: The model uses annotated points to adjust future bounds, so feedback immediately improves accuracy.

See [Annotate bounds](https://docs.datadoghq.com/monitors/types/data_observability.md#annotate-bounds) on the Data Observability Monitor page for available annotation types and how to apply them.

## Further reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Quality Monitoring](https://docs.datadoghq.com/data_observability/quality_monitoring.md)
- [Data Observability Monitor](https://docs.datadoghq.com/monitors/types/data_observability.md)