Purpose and workload fit
Repeats the corresponding observations from the preceding cycle. A seasonal baseline for repeating demand; anomalies in that cycle are repeated too.
History and runtime requirements
At least season_length_steps observations: one full cycle.
Inputs must be regularly sampled, gap-free, and finite. Outputs retain the metric unit, such as CPU cores, memory bytes, or requests per second. The sample interval determines the duration of a step. Minimum history permits execution; it does not establish forecast quality.
This method does not use covariates; target metrics are forecast separately.
Parameter reference
On narrow screens, swipe the parameter table horizontally to read all columns.
| Parameter / type | Default / range / unit | Meaning and use |
|---|---|---|
season_length_stepsint | Required; no default ≥ 2; steps | Season length in sample steps; zero disables seasonality where allowed. Seasonal Naive requires an explicit cycle. |
Configuration example
Edit parameters in Algorithm management. This is a parameter object, not a complete config.yaml. Seasonal examples assume five-minute sampling; adjust for your actual interval. Omitted optional values use the defaults above.
{
"season_length_steps": 288
}Tuning and tradeoffs
Convert the business cycle into sample steps. A day is 288 steps at five-minute sampling or 1440 at one-minute sampling; 24 is not automatically a day.
Use in a module
- Save parameters and check history, sample interval, and horizon.
- Enable module prediction. Fixed mode runs the selected method; dynamic mode uses centrally enabled methods.
- This baseline does not need backtest promotion, but actual performance still needs review.
- Review error, peak underestimation, runtime, and adoption reasons in Observe or Recommend before separately authorizing admission and replica actions.
For insufficient history, invalid settings, timeouts, or invalid output, inspect run reasons. Without eligible forecasts, the module follows its schedules, fallback, and protection rules.