Guides
Time series analysis, explained
How analysts model data ordered in time — the patterns forecasting methods look for, the pitfalls, and where the data actually lives.
A time series is nothing more than a sequence of values ordered by time — daily revenue, hourly server load, monthly unemployment. What makes it its own field of analytics, rather than just another column in a spreadsheet, is that order matters: yesterday's value tells you something about today's in a way that unrelated rows in a normal dataset never do. Every method in this guide exists to exploit, or correct for, that dependency.
The questions people ask
Two distinct jobs get lumped under "time series analysis," and confusing them is the single most common source of frustration with the field. The first is forecasting: given the past, what happens next — next month's demand, next quarter's revenue, next hour's server load. The second is monitoring and detection: is what's happening right now normal, and if not, when did it stop being normal. A retail team forecasting holiday demand and a platform team alerting on a latency spike are both doing "time series analysis," but they need different tools and different levels of urgency.
The data it runs on
Time series data is defined by its structure, not its subject matter: a timestamp, a value (or several), and — usually — a fixed or near-fixed interval between observations. That regularity is what separates it from a general event log; a time series is typically already aggregated to a cadence (per minute, per day, per month) rather than a raw stream of arbitrary timestamped events. Sources range from financial prices and IoT sensor readings to infrastructure metrics, web traffic and macroeconomic indicators — different domains, same underlying shape.
Core methods and how to read them
Stationarity is the property most classical forecasting methods assume: that a series' statistical characteristics — mean, variance, the way it correlates with its own past — don't change over time. Most real series aren't stationary in their raw form (sales trend upward, prices drift), which is why the first step in classical modeling is often transforming a series (differencing it, removing a trend) until it approximately is.
Seasonality is a regular, repeating pattern tied to the calendar or clock — retail sales spiking every December, web traffic dipping every weekend. Distinguishing genuine seasonality from a one-off trend is foundational: a model that treats a single unusual spike as a recurring seasonal pattern will keep forecasting a repeat that never comes.
Autocorrelation measures how strongly a series is correlated with a lagged version of itself — today's value against yesterday's, or against the same day last week. It's the formal way of asking "how much does the past actually predict the near future here," and it's the diagnostic tool used to identify how far back a model needs to look.
The moving average smooths a series by averaging each point with its neighbors over a fixed window, MA_t = (x_t + x_{t-1} + ... + x_{t-n+1}) / n, trading responsiveness to real changes for reduced noise. It's the simplest possible forecasting and smoothing tool, and a reasonable baseline to beat before reaching for anything more sophisticated.
Exponential smoothing improves on a simple moving average by weighting recent observations more heavily than older ones, with the weight decaying exponentially into the past. Extensions of the technique (Holt-Winters) add explicit trend and seasonal components, making it a common, interpretable choice for business forecasting before reaching for machine learning.
ARIMA (AutoRegressive Integrated Moving Average) combines autoregression (a value predicted from its own past values), differencing (to address non-stationarity) and a moving-average error term into one classical statistical model, and remains a standard benchmark that newer forecasting methods are routinely measured against. It requires more setup and statistical judgment than exponential smoothing but can capture more complex dynamics in a single series.
Time series forecasting is the umbrella outcome all of the above serve: a projection of future values, ideally with an honest uncertainty interval around it rather than a single confident number, since the further out a forecast reaches, the less any method — classical or modern — should be trusted to be precise.
How the work is done in practice
Forecasting work today splits between classical statistical methods and libraries built for scale or automation. Prophet, built by Meta's data science team, is a common first choice: it fits trend, seasonality and holiday effects with minimal tuning, aimed at analysts who want a fast, interpretable forecast rather than a hand-tuned model — though its simplicity means it handles a single dominant seasonal pattern well and struggles with more complex, interacting seasonalities. Darts takes the opposite approach, offering one consistent interface across dozens of model families — classical, gradient-boosted, deep-learning and foundation models — so a team can benchmark several approaches against the same data without rewriting pipeline code for each. Nixtla is built for scale specifically: its open-source libraries fit statistical and machine-learning models across millions of individual series in parallel, and its hosted TimeGPT product offers forecasting via API with no model training required.
Separately from forecasting, a time-series database is the storage layer purpose-built for high-volume, time-stamped writes and time-range queries — the operational backbone under most monitoring and IoT use cases. Prometheus is the de facto standard for infrastructure and Kubernetes metrics, paired almost universally with Grafana for visualization. InfluxDB is a purpose-built alternative for metrics, sensor and IoT data with both self-hosted and managed cloud options. TimescaleDB takes a different route, adding time-series performance as an extension to PostgreSQL itself, useful for teams who want full SQL and joins rather than a specialized query language.
Common mistakes and misreadings
Fitting a model to a non-stationary series without transforming it first. Classical models built on the assumption of stationarity will produce systematically biased forecasts on a series with an untreated trend.
Mistaking a one-time event for seasonality. A model that "learns" a pandemic-era spike as a recurring seasonal pattern will keep expecting it to recur.
Reporting a point forecast with no uncertainty interval. A single number implies more confidence than any forecasting method actually has, especially several periods out; the interval is not an optional extra.
Confusing correlation with a lagged variable for causation. High autocorrelation means the past predicts the future statistically — it says nothing about why, and using it to infer a causal driver is a common overreach.
Using a monitoring threshold built for a stationary metric on a seasonal one. An alert tuned to flag "unusually high" traffic without accounting for the normal weekday/weekend pattern will fire constantly on Mondays and miss real anomalies on Sundays.
For where forecasting fits alongside other predictive methods, see every forecasting tool in this category and every time-series database in this category.