Forecasts Monitor


Forecasting is an algorithmic feature that allows you to predict where a metric is heading in the future. It is well-suited for metrics with strong trends or recurring patterns. For example, if your application starts logging at a faster rate, forecasts can alert you a week before a disk fills up, giving you adequate time to update your log rotation policy. Or, you can forecast business metrics, such as user sign-ups, to track progress against your quarterly targets.

Monitor creation

To create a forecast monitor in Datadog, use the main navigation: Monitors –> New Monitor –> Forecast.

Define the metric

Any metric currently reporting to Datadog is available for monitors. For more information, see the Metric Monitor page.

After defining the metric, the forecast monitor provides two preview graphs in the editor:

Editor graphs

  • The Historical View lets you explore the past metric data at different time scales.
  • The Evaluation Preview shows a combination of historical and predicted metric data.

Set alert conditions

  • Trigger an alert when the edge of the forecast confidence bounds goes above or below.
  • the threshold within the next 24 hours, 1 week, 1 month, etc. or custom to set a value between 12 hours and 3 months.
  • Alert threshold: >= <NUMBER>
  • Warning threshold: >= <NUMBER>
  • Alert recovery threshold: < <NUMBER>
  • Warning recovery threshold: < <NUMBER>

Advanced options

Datadog automatically analyzes your chosen metric and sets several parameters for you. However, the options are available to edit under Advanced Options:

Advanced options
AlgorithmThe forecast algorithm (linear or seasonal)
ModelThe forecast model (default, simple, or reactive) for the linear algorithm
SeasonalityThe forecast seasonality (hourly, daily, or weekly) for the seasonal algorithm
Daylight savingsAvailable for seasonal forecast monitors with daily or weekly seasonality.
RollupThe rollup interval—larger intervals between points avoid noise influence on the forecast.
DeviationsThe width of the range of forecasted values—a value of 1 or 2 is generally large enough for most “normal” points.

The available forecast algorithms are linear and seasonal:

Use the linear algorithm for metrics that have steady trends but no repeating seasonal pattern. There are three different models which control the linear algorithm’s sensitivity to level shifts:

DefaultAdjusts to the most recent trend and extrapolates data while being robust to recent noise.
SimpleDoes a robust linear regression through the entire history.
ReactiveExtrapolates recent behavior better at the risk of overfitting to noise, spikes, or dips.
linear default
linear simple
linear reactive

Use the seasonal algorithm for metrics with repeating patterns. There are three different seasonality choices:

HourlyThe algorithm expects the same minute after the hour behaves like past minutes after the hour, for example 5:15 behaves like 4:15, 3:15, etc.
DailyThe algorithm expects the same time today behaves like past days, for example 5pm today behaves like 5pm yesterday.
WeeklyThe algorithm expects that a given day of the week behaves like past days of the week, for example this Tuesday behaves like past Tuesdays.

Note: This algorithm requires at least two seasons of history and uses up to six seasons for forecasting.


Advanced alert conditions

For detailed instructions on the advanced alert options (no data, evaluation delay, etc.), see the Monitor configuration page. For the metric-specific option full data window, see the Metric monitor page.


For detailed instructions on the Configure notifications and automations section, see the Notifications page.


To create forecast monitors programmatically, see the Datadog API reference. Datadog strongly recommends exporting a monitor’s JSON to build the query for the API. By using the monitor creation page in Datadog, customers benefit from the preview graph and automatic parameter tuning to help avoid a poorly configured monitor.

Forecast monitors are managed using the same API as other monitors, but the contents of the query property deserves further explanation.

The query property in the request body should contain a query string in the following format:

<aggregator>(<query_window>):forecast(<metric_query>, '<algorithm>', <deviations>, interval=<interval>[, history='<history>'][, model='<model>'][, seasonality='<seasonality>']) <comparator> <threshold>
  • aggregator: Use min if the alert should trigger when the forecast goes below the threshold. Use max if the alert should trigger when the forecast goes above the threshold.
  • query_window: A timeframe, for example: next_4h or next_7d.
  • metric_query: A standard Datadog metric query, for example:{service:database,device:/data}by{host}.
  • algorithm: linear or seasonal
  • deviations: A number greater than or equal to one. This parameter controls the size of the confidence bounds, allowing a monitor to be made more or less sensitive.
  • interval: A positive integer representing the number of seconds in the rollup interval.
  • history: A string representing the amount of past data that should be used for making the forecast, for example: 1w, 3d. This parameter is only used with the linear algorithm.
  • model: The type of model to use: default, simple, or reactive. This parameter is only used with the linear algorithm.
  • seasonality: The seasonality to use: hourly, daily, or weekly. This parameter is only used with the seasonal algorithm
  • comparator: Use <= to alert when the forecast goes below the threshold. Use >= to alert when the forecast goes above the threshold.
  • threshold: A critical alert will trigger when the forecast’s confidence bounds reach this threshold.


The following functions cannot be nested inside calls to the forecast() function:
anomalies, cumsum, integral, outliers, piecewise_constant, robust_trend, or trend_line

Further Reading