Outlier Monitor
An outlier monitor is a Datadog monitor type that compares multiple series in a group with the same role against one another, finds the series whose behavior differs from its peers, and notifies. Unlike anomaly detection, which compares against your own past, it compares against your peers at the same point in time.
Overview
An outlier monitor is a Datadog monitor type that lines up, series by series, a metric split by a group such as host or availability zone, and detects as an outlier any series that behaves differently from the rest. The yardstick for the judgment is not your own past but the values of your peers in the same time period. The group needs 3 or more members that behave homogeneously; with too few series there is no one to compare against and it does not work. There are two families of algorithms, DBSCAN and MAD, and both adjust the size of the difference permitted with tolerance. It matters when you operate servers or partitions with the same configuration side by side and want to catch the state in which just one of them is quietly starting to break, before it is buried under a threshold on the whole.
A monitor that finds the one that differs from its peers
The Outlier Monitor is one type of monitor, and it detects that a certain group is behaving differently from the other groups among its peers. The official documentation gives two examples: when only one web server in a pool is handling an abnormal number of requests, and when only one AWS availability zone has conspicuously many 500 errors (as of September 2026; Source: Outlier Monitor). As a prerequisite, the metric must be split by a group such as host, availability zone, or partition, and there must be 3 or more members that behave homogeneously. Notifications go out separately for each group judged to be an outlier. The time window to evaluate can be chosen from options such as the last 5 minutes / 15 minutes / 1 hour, or specified in a range from 1 minute to 1 year.
Anomaly detection and forecasting compare against something different
The three types that sit together in the same "anomaly detection family" are easy to keep straight if you distinguish them by what they compare against. The anomaly monitor compares against your own past trajectory, and the forecast monitor compares against your own projected future. Only the outlier monitor compares against your peers at the same point in time. This difference determines the shape of the failures that can be detected. A failure in which all members deteriorate in unison produces no difference from peers, so it does not show up in an outlier monitor. Conversely, degradation of just one host, which gets buried under a threshold that looks at the overall average or total, is the shape an outlier monitor picks up fastest. Therefore an outlier monitor is placed not as a replacement for the threshold that protects the whole, but as an auxiliary line that specializes in watching for isolation within a homogeneous group lined up side by side.
DBSCAN and MAD - two families of algorithms and tolerance
There are two families of algorithms, the DBSCAN family and the MAD family, and each has a scaled version, scaledDBSCAN and scaledMAD. The official documentation recommends the default DBSCAN, and advises trying parameter adjustment or switching to MAD when it does not pick up the correct outliers (as of September 2026; Source: Outlier Monitor). DBSCAN has a single parameter, tolerance, and the larger you make it the more widely it permits deviation from the peers. MAD uses the median absolute deviation as its yardstick and has two settings: tolerance (how many deviations away from the median a point must be to be considered an outlying point) and % (if the proportion of outlying points within a group exceeds this value, the whole group is considered an outlier). The scaled versions are the option for when values are large in scale and the series are densely clustered together, and you want the judgment to stretch and shrink according to the scale.
- Place each group's series as a single point whose dimensions are the number of points in the time series
- Take the median of all groups at each timestamp to create a median series
- Measure the Euclidean distance between each group and the median series
- Multiply the median of the distances by a normalization constant for the initial threshold, and multiply by tolerance for the distance parameter
- Points that did not fall into the largest cluster are outliers
The length of the time window separates misses from oversensitivity
What the official documentation lists as an important consideration at configuration time is the time window. If the window is too long, the notification comes too late; if it is too short, it becomes oversensitive to one-off spikes (as of September 2026; Source: Outlier Monitor). For tuning, a procedure is provided in which you change the window on the preview graph and use the rewind button to go back into the past, confirming "the outliers that would have fired with this setting." The same procedure also works for choosing the algorithm. In the example in the official documentation, when multiple hosts flush their buffers at the same time and just one is slightly late, DBSCAN judges it an outlier and MAD does not. If they are only aligned as a byproduct of a simultaneous restart, MAD is the fit; if it is a scheduled job that should move in unison, DBSCAN is the correct choice. In other words, "does being aligned have meaning in itself?" is the question to ask when choosing between the two families.
Groups that split into bands should be watched band by band
The typical case where an outlier monitor does not work is when the group's series split into multiple bands. If the level differs per shard, the bands make each other look like outliers before a single isolated series can be found. The official documentation recommends attaching an identifying tag to each band and configuring outlier monitoring separately per band (as of September 2026; Source: Outlier Monitor). A group with fewer than 3 members also does not work, because there are not enough peers to compare against. What it suits is groups that are supposed to be homogeneous, such as hosts or Pods with the same role, queue partitions lined up with the same configuration, or multiple availability zones. The overview of when to use it versus a threshold protecting the whole or anomaly detection is left to the monitors guide. Placing an outlier monitor also means continuously verifying, day after day, the design assumption that "these are supposed to be homogeneous."