Forecast Monitor
A Forecast Monitor is a Datadog monitor type that predicts a metric's future values from its past trend and notifies you at the point where the edge of the forecast band is expected to reach the threshold within a specified period of 12 hours to 3 months ahead. It tells you "when it will run out" for a value that moves in one direction, such as disk usage, before it runs out.
Overview
A forecast monitor is a Datadog monitor type that estimates a metric's future values from its past trend and notifies you when the forecast is expected to reach the threshold. What is used for the judgment is not the forecast value itself but the edge of the confidence interval band, and it fires when the time at which the band crosses the threshold falls within the specified look-ahead period (12 hours to 3 months). There are two algorithms, linear, which extends a linear trend, and seasonal, which factors in repetition by time of day or day of week, and you choose based on the nature of the target value. You care about it in capacity planning, that is, when you want to act on a value heading toward full, such as disk or connection count, before it becomes full. Compared with an anomaly monitor, which checks whether the current value differs from usual, the direction in time it looks is reversed.
A monitor that tells you in advance when the threshold will be reached
A Forecast Monitor is one type of monitor; it estimates a metric's future values from its past trend and notifies you at the point where the forecast is expected to reach the threshold. The official documentation gives the example of being notified a week before a disk fills up when log output starts to increase, and the example of checking a business indicator such as user sign-ups against a quarterly target (as of September 2026; Source: Forecasts Monitor). The notification condition is "whether the edge of the forecast's confidence interval band crosses above or below the threshold within the specified look-ahead period". The look-ahead period is chosen from 24 hours / 1 week / 1 month, or specified freely in the range of 12 hours to 3 months. The decisive difference from other types is that it fires not on the fact of having crossed the threshold but on the expectation of crossing it.
Compared with an anomaly monitor, the direction in time it looks is reversed
The one it is easy to confuse with is the anomaly monitor. Anomaly detection checks "whether the current value is within the band expected from the past trend", so its gaze points from the past toward now. A forecast monitor checks "whether the edge of the band will reach the threshold from here on", so its gaze points from now toward the future. Both build a band from history, but the anomaly detection band is the yardstick for judging the current value, while the forecast band is the expected range of future values. Watchdog, the built-in detection that works without configuration, is also anomaly detection based on past trends and is not a mechanism that foretells when a threshold will be reached. In the query too, the two are separate functions. You cannot nest the anomaly detection anomalies() or the outlier outliers() inside the forecast forecast() (as of September 2026; Source: Forecasts Monitor).
linear and seasonal - extend or repeat
There are two algorithms: linear and seasonal. linear suits values that have a steady trend but no repeating cycle, and draws the future by extending a straight line. seasonal suits values that repeat the same shape by time of day or day of week, and draws the future by overlaying past cycles. Datadog analyzes the selected metric and sets each item automatically (as of September 2026; Source: Forecasts Monitor). The safe order is to first look at the forecast line in the evaluation preview with the automatic settings as they are, and touch the advanced options only when it does not match your intuition. The item names in the table follow the notation of the official documentation.
| Item | linear | seasonal |
|---|---|---|
| Suited values | Values with a trend but no cycle | Values that repeat by time of day or day of week |
| Choices that determine the shape | model = default (follows the recent trend while being robust to noise) / simple (robust linear regression over the whole history) / reactive (extends the recent data closely but tends to overfit noise and sudden values) | seasonality = hourly / daily / weekly. For daily and weekly, daylight saving time transitions can also be specified |
| Handling of history | history specifies the length of the past used for the forecast (e.g. 1w / 3d) | Requires at least 2 cycles of history, and uses up to 6 cycles for the forecast |
| Common tuning | Deviations = width of the band (1 or 2 covers the large majority of normal points) / Rollup = aggregation interval (widening it makes the forecast less affected by noise) | |
Reading the shape of the query shows what is being forecast
When creating one via the API, the query follows the skeleton shown in the official documentation (as of September 2026; Source: Forecasts Monitor). For the leading aggregator, choose max to watch for crossing above and min to watch for crossing below; the window that follows, such as next_7d, is the look-ahead period. Inside forecast() you line up the query for the target metric, the algorithm name, the deviations that determine the width of the band (a number of 1 or more), and the interval, the aggregation interval (in seconds). For linear you add history and model to that; for seasonal, seasonality. The comparator at the end is >= for crossing above and <= for crossing below, and to its right is the threshold. The official documentation strongly recommends exporting the JSON of a monitor built in the UI and copying its query rather than assembling this string by hand. Over which window, with what width, and from which history the forecast is built all appear in this single line.
Suitable and unsuitable indicators - guidelines for use in capacity planning
What suits it are values that move in one direction with a trend, such as disk usage, remaining storage capacity, the number of items backed up in a queue, and utilization against a connection limit. The premise on which a forecast holds is that "the trend or cycle so far will continue from here on", so for values that move in steps or spikes with every release or incident, the line to be extended is not even determined in the first place. If you leave such values to static thresholds or anomaly detection and confine forecast monitors to foretelling capacity and exhaustion, the division of roles becomes clear. For new metrics with insufficient history, seasonal cannot be used until 2 cycles of history have accumulated. The arrangement is to protect with a static threshold until it accumulates, and switch over afterward. The list of when to use anomaly detection or outliers instead is left to the Monitors explainer. If you also write into the notification body what to do when the forecast turns out wrong, the recipient can judge on the spot whether "there is still headroom, or I act now".