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.
To create a forecast monitor in Datadog, use the main navigation: Monitors –> New Monitor –> Forecast.
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:
1 month, etc.
Datadog automatically analyzes your chosen metric and sets several parameters for you. However, the options are available to edit under Advanced Options:
|Algorithm||The forecast algorithm (|
|Model||The forecast model (|
|Seasonality||The forecast seasonality (|
|Daylight savings||Available for |
|Rollup||The rollup interval—larger intervals between points avoid noise influence on the forecast.|
|Deviations||The 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
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:
|Default||Adjusts to the most recent trend and extrapolates data while being robust to recent noise.|
|Simple||Does a robust linear regression through the entire history.|
|Reactive||Extrapolates recent behavior better at the risk of overfitting to noise, spikes, or dips.|
Use the seasonal algorithm for metrics with repeating patterns. There are three different seasonality choices:
|Hourly||The 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.|
|Daily||The algorithm expects the same time today behaves like past days, for example 5pm today behaves like 5pm yesterday.|
|Weekly||The 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.
For detailed instructions on the Say what’s happening and Notify your team sections, 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.
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>
minif the alert should trigger when the forecast goes below the threshold. Use
maxif the alert should trigger when the forecast goes above the threshold.
query_window: A timeframe, for example:
last_7d. The timeframe is recommended to be around five times the
alert_window, but it must be at least as large as
alert_window. This parameter controls the time range displayed in graphs included in notifications.
metric_query: A standard Datadog metric query, for example:
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:
3d. This parameter is only used with the
model: The type of model to use:
reactive. This parameter is only used with the
seasonality: The seasonality to use:
weekly. This parameter is only used with the
<=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