Time Series in Production: Forecasting and Anomaly Detection That Stays Accurate

A forecast nobody refreshes is a liability. Here's how we ship demand forecasting, KPI anomaly detection, and monitored time series pipelines: the methods, the pitfalls, and what production actually requires.

A forecast chart wins a meeting. Six months later nobody trusts it because seasonality moved, someone changed the metric definition, and the job that refreshes scores has been red for two weeks.

Production time series work means backtests before launch, scheduled refresh, alerts when reality leaves the band, and a named owner when the model is wrong.

Forecasting

How many orders next week?
Staffing and inventory planning
Needs confidence intervals planners understand
Wrong when seasonality or promos shift

Anomaly detection

Is today's metric normal for a Tuesday in March?
Ops and fraud alerts
Needs plain language: expected range vs actual
Wrong when baseline drifts unchecked

Many teams need both on the same underlying metric.

What makes real-world series hard

Missing and irregular timestamps: systems go down, pipelines lag, definitions change mid-year
Multiple seasonality: day-of-week, month, holidays, promotional calendars stacked together
Regime changes: COVID, pricing changes, product launches that permanently shift the baseline
Coarse aggregation hiding problems: daily totals look fine; hourly shows the outage
Human intervention: planners override forecasts; your eval must account for how outputs are actually used

If a vendor shows you a perfect fit on historical data without discussing these, ask what happens next quarter.

Methods: start simple, add complexity when earned

Baselines that often win

Seasonal naive (last year same week), moving averages, ETS, and Prophet handle a surprising share of business forecasting, especially at weekly or monthly grain with clear seasonality. They're interpretable and fast to refresh.

When to add ML

Many related series (every SKU, every store), rich exogenous features (weather, promotions, price), or complex interactions: gradient boosting and global forecasting models (e.g. hierarchical reconciliation across regions) can outperform. The cost is engineering complexity and harder explainability for finance stakeholders.

Anomaly detection approaches

Residuals from a forecast model, statistical control charts on rolling windows, or isolation-based methods on engineered features. For operations teams, plain language matters: "expected range 1,200–1,450 orders; today 890, investigate" beats a raw anomaly score.

Production checklist

Before you call it production

Backtest on rolling windows, not the same period you trained on
Lock metric definition (orders vs revenue if refunds lag)
Scheduled refresh with automated pulls
Track MAPE or wMAPE over time; alert when error drifts
Log planner overrides for the next model iteration
Runbook when the pipeline fails or forecasts look wrong

High-frequency and streaming series

Fraud scoring, API metrics, and IoT telemetry operate at seconds or minutes, not days. Patterns include rolling aggregations, exponential decay features, and models scored in stream processors. Our federal fraud detection engagement is a time series problem at 10TB+ daily: distributions shift, concepts drift, and monitoring is non-optional.

Pairing time with location

Many growth questions need both axes: demand where and when. Regional seasonality, store-level forecasts, and geo-segmented trends combine time series analytics with geospatial work. Build each foundation cleanly before merging. Bad addresses and bad timestamps compound.

What we won't do

Ship a one-time forecast with no refresh plan
Hide poor backtest accuracy behind a slick dashboard
Use deep learning by default when seasonal naive would ship faster and explain better
Ignore how planners, finance, or ops will actually consume the output