Time Series in Production: From Prophet to Foundation Models — and When Survival Analysis Is What You Actually Need

Two things are true about time series in production in 2026: foundation models like Google's TimesFM and Amazon Chronos genuinely work well out of the box for a broad class of forecasting problems, and Prophet — released by Meta in 2017 — is still the right choice for the majority of business forecasting tasks at most organizations. Both of these are correct simultaneously, and knowing which applies to your problem is the gap between a productive month and an expensive detour.

But there is a third thing that most ML practitioners miss: a significant fraction of problems that arrive dressed as forecasting questions are actually survival analysis problems in disguise. "How many users will churn next month?" is a forecasting question. "Which users are at risk, given how long they have already been active?" is a survival question. Confusing the two costs precision, interpretability, and sometimes the entire production model.

1. Classical Time Series: ARIMA, ETS, and Prophet — Still the Workhorses

The classical toolkit is not legacy software that foundation models have replaced. It is a set of production-tested, auditable, fast-to-deploy methods that outperform deep learning on the majority of real business time series — especially the short, irregular, or low-frequency series that dominate enterprise demand planning, financial reporting, and operational analytics.

ARIMA / SARIMA

AutoRegressive Integrated Moving Average models remain the statistical standard for univariate series with clear autocorrelation structure. SARIMA (Seasonal ARIMA) extends this with explicit seasonal components. They excel when the series is relatively stationary after differencing, the dataset is small (hundreds to low thousands of observations), and the forecasting horizon is short (days to weeks). Their key limitations are manual order selection (partially addressed by auto_arima in the pmdarima library), inability to incorporate exogenous covariates cleanly at scale, and poor handling of multiple seasonalities — a weekly pattern nested inside an annual pattern is awkward to express in a single SARIMA model.

Exponential Smoothing (ETS)

State Space models for exponential smoothing — Error, Trend, Seasonality — are the backbone of the statsmodels ETS implementation and Holt-Winters. They fit faster than ARIMA, handle seasonality natively, and produce calibrated prediction intervals through state-space formulations. For retail and supply chain demand planning — weekly or monthly series, seasonal patterns, thousands of SKUs — ETS-family models remain extremely competitive and are often the right choice before reaching for anything more complex. The M-Competitions (M4, M5) consistently show ETS and Theta methods beating deep learning on typical business forecasting problems.

Prophet

Meta's Prophet (2017) solved a specific and common problem: business analysts needed to forecast daily or sub-daily series with strong weekly seasonality, known holiday effects, and occasional trend changepoints — without having to specify ARIMA orders or debug stationarity. Prophet's additive decomposition (trend + seasonality + holidays + noise) is intuitive, its Python and R APIs are clean, and it handles missing data gracefully. It produces reasonable probabilistic intervals via Bayesian sampling (Stan under the hood).

Prophet's real-world limitation is that it assumes a single additive decomposition that holds through time. When the relationship between trend and seasonality changes — as it did dramatically during COVID-19 for virtually every consumer time series — Prophet fits a single model to a fundamentally non-stationary process and degrades sharply. Its multiplicative seasonality mode helps when amplitude scales with trend, but it remains a single-series model with no mechanism for cross-series transfer learning. For a handful of series with clean patterns, Prophet is hard to beat on speed-to-production. For thousands of series with heterogeneous behavior, you need something else.

2. ML Approaches: LightGBM and XGBoost for Time Series

Gradient-boosted trees are not naturally temporal models — they make i.i.d. assumptions that time series violate. The key is feature engineering: transform a sequential prediction problem into a supervised tabular one, and trees' tabular-data strengths apply directly.

The feature engineering recipe

The standard recipe for LightGBM time series:

• Lag features: y(t-1), y(t-7), y(t-14), y(t-28) — the signal's own recent past
• Rolling statistics: 7-day mean, 14-day std, 28-day median — local context without look-ahead
• Calendar features: day of week, month, is_weekend, is_holiday (critical for retail, AdTech, telecom)
• Fourier features: sin(2πt/P) and cos(2πt/P) for period P — encode seasonality without explicit seasonal models
• Exogenous features: price, temperature, campaign spend, competitor activity — anything correlated with the target

The power of this approach is that any feature available at forecast time can be used — no special treatment needed. A retail chain that knows planned promotions, weather forecasts, and school calendars two weeks in advance can include all of that information as features. ARIMA and Prophet cannot consume arbitrary future covariates this naturally.

The limitation is the training objective: GBDT models train on point predictions and do not inherently understand temporal dependencies beyond the lags you engineer. Autocorrelation structure that ARIMA captures implicitly must be explicitly encoded. And for long-horizon forecasting (more than a few periods ahead), recursive multi-step prediction through a GBDT accumulates errors — direct multi-output strategies or specialized architectures are needed.

When GBDT for time series wins

The regime where LightGBM/XGBoost consistently outperforms classical methods: (1) rich exogenous features exist and matter, (2) multiple related series can share a model (global model across all SKUs or markets), (3) non-linear feature interactions drive the signal (promotional effects that interact with seasonality), or (4) the series have irregular patterns that fit neither ARIMA's autocorrelation structure nor Prophet's additive decomposition. The M5 competition (Walmart sales forecasting) — the most rigorous real-world time series benchmark to date — was dominated by LightGBM-based global models with extensive feature engineering.

3. Deep Learning: Foundation Models vs. Architecture-Specific

Foundation models (2023–2024)

The last two years produced four significant time series foundation models, each trained on massive corpora of diverse time series to enable zero-shot or few-shot forecasting on new series:

• TimesFM (Google, 2024): A 200M parameter decoder-only Transformer trained on 100B time points from Google's internal datasets plus public corpora. Handles arbitrary context lengths via patching (similar to PatchTST). Zero-shot performance competitive with — or better than — task-specific models on M4 and ETT benchmarks. Available as an open-weight model.
• Amazon Chronos (2024): Frames time series forecasting as a language modeling problem — tokenizes time series values via quantization, then trains a T5-style seq2seq model on a large corpus of real and synthetic series. Produces probabilistic forecasts naturally (via sampling from the generative model). Open-source under Apache 2.0; scales from Tiny (8M params) to Large (710M params).
• Salesforce MOIRAI (2024): Trained on the LOTSA dataset (27B observations across 9 domains), MOIRAI uses a unified training approach with patch-based encoding that handles variable frequencies (hourly, daily, weekly, monthly) natively. Competitive zero-shot performance on M4, ETT, and Weather benchmarks without any finetuning.
• Lag-Llama (2024): A decoder-only LLM adapted for time series via lag features as tokens, trained on a diverse mix of public datasets. Produces probabilistic forecasts through autoregressive sampling. Particularly strong on low-frequency (weekly, monthly) series and business data.

Architecture-specific deep learning models

Beyond foundation models, the dedicated deep learning architectures for time series are mature enough to use in production with appropriate investment:

• Temporal Fusion Transformer (TFT): Google's interpretable multi-horizon forecasting architecture (2020) handles multi-variate inputs, static covariates, future-known inputs, and past observations in a unified attention-based architecture. The variable selection network and interpretable multi-head attention provide output that resembles feature importance — useful when stakeholders need to understand what the model is using. TFT consistently ranks highly in multivariate long-horizon benchmarks and is available in GluonTS and PyTorch Forecasting.
• N-BEATS / N-HiTS: Pure MLP-based architectures (no attention, no recurrence) that decompose the forecast into interpretable trend and seasonality stacks (N-BEATS Interpretable). N-HiTS adds hierarchical interpolation and multi-rate sampling, enabling efficient long-horizon forecasts. Both are fast to train, architecturally simple, and highly competitive on M4 and M5.
• PatchTST: Applies the Vision Transformer's patch-based approach to time series — divides the series into non-overlapping patches, treats each as a token, and applies self-attention across patches. Extremely efficient on long sequences and strong on long-horizon univariate forecasting benchmarks (ETT, Weather, Exchange).
• TiDE (Time-series Dense Encoder): A dense MLP-based encoder-decoder that matches Transformer performance at a fraction of the compute. Training is fast, inference is cheap, and it handles exogenous features and multiple output horizons natively. Often the right choice when you need DL-level accuracy without Transformer-level serving cost.

4. The Production Comparison: Accuracy, Complexity, and Overhead

5. Production Considerations: Where Forecasting Systems Actually Break

Backtesting without leakage

The most common silent error in time series ML is data leakage during evaluation. Using a random train-test split on a temporal dataset means your model "sees" future data during training — e.g., lag features computed from the test set, or a scaler fitted on the full dataset. The correct approach is walk-forward (expanding window) or rolling-window cross-validation, where the cutoff point is strictly enforced: no feature from time t+1 onward may be used when evaluating at time t. The TimeSeriesSplit in scikit-learn implements this; GluonTS's backtest evaluator does so natively for DL models. Kaggle time series competitions are won and lost on leakage detection.

Concept drift and model staleness

Time series models trained on historical data degrade as patterns shift — promotional strategies change, competitors enter, macroeconomic conditions shift. Production-grade forecasting systems need drift detection: statistical tests on residual autocorrelation (Ljung-Box), MAPE/WAPE monitoring with alert thresholds, and automatic retraining triggers. For foundation models, the advantage is that zero-shot inference adapts the context window without retraining — the model "sees" recent observations as input and updates its predictions implicitly.

Cold-start for new series

Classical models and per-series GBDT models require a minimum history length to produce meaningful forecasts — typically at least two seasonal cycles (two years for annual seasonality). New product launches, new stores, new market entries — all hit this cold-start problem. Global LightGBM models handle cold-start through cross-series transfer: a new SKU from a known category gets predictions informed by all other SKUs the model has seen. Foundation models handle it even more gracefully — a new series with as few as 50 data points is reasonable context for TimesFM or Chronos zero-shot inference.

Probabilistic vs. point forecasts

A point forecast is almost always the wrong output for a production decision system. Inventory planning needs a prediction interval — how much safety stock to hold depends on forecast uncertainty, not just the mean. Chronos and Lag-Llama produce probabilistic distributions natively via sampling. TFT produces quantile forecasts. For classical models, bootstrap conformal prediction or direct quantile regression provides calibrated intervals. If your downstream system only consumes point forecasts, you are likely making systematically suboptimal decisions — over- or under-provisioning based on a point estimate that carries no uncertainty information.

6. Survival Analysis: The Tool Most ML Teams Never Reach For

Survival analysis is a family of statistical and ML methods designed for time-to-event data — problems where the outcome of interest is how long until something happens, and — critically — where you do not always observe the event for every subject. This latter property, called censoring, is what distinguishes survival analysis from regression.

What censoring means in practice

Consider a telecom company tracking customer churn. You observe customers from their activation date. At the time of analysis, some customers have already churned — you know their exact time-to-event. But many are still active — they have not churned yet, but they might in the future. These customers have right-censored survival times: you know they survived at least until the observation date, but not how much longer. A regression model that treats their current tenure as the "true" outcome discards survival information. A survival model correctly uses their entire observed history as evidence of survival, then estimates the probability of churning at any future time point.

"The moment you have time-to-event data with any customers still active, you have right-censored data. Fitting logistic regression on a binary 'churned within 90 days' target is answering a different question — and usually the wrong one."

Kaplan-Meier and Cox Proportional Hazards — still the workhorses

The Kaplan-Meier estimator is the non-parametric, covariate-free survival curve: it gives you the probability of surviving past time t, computed directly from event and censoring counts at each observed time point. Use it first, always — it is the correct descriptive visualization for any survival problem, and it reveals cohort differences (subscribers acquired in month X vs month Y) that aggregate churn metrics obscure.

The Cox Proportional Hazards model extends this to covariates: it estimates how customer features (tenure, plan type, usage level, NPS score) modulate the baseline hazard rate. The proportionality assumption — that the hazard ratio between two covariate values is constant over time — is a genuine constraint, but it holds approximately for most business use cases. Cox PH is implemented in the lifelines Python library with a scikit-learn compatible API, and its coefficients are directly interpretable as log-hazard ratios.

7. ML and Deep Learning for Survival Analysis

Random Survival Forests (RSF)

Applying random forests to survival data requires a modified splitting criterion — the log-rank test or concordance index, rather than variance reduction. RSF handles non-proportional hazards (where the Cox assumption fails), non-linear covariate effects, and high-dimensional features without manual variable selection. The scikit-survival library implements RSF with a consistent API. In practice, RSF outperforms Cox PH when: (1) you have many features (>30) and expect non-linear interactions, (2) the proportionality assumption is violated (testable via Schoenfeld residuals), or (3) you have a mix of continuous and categorical covariates with complex structure.

DeepSurv

DeepSurv replaces Cox PH's linear predictor with a deep neural network — a multi-layer feedforward network that outputs the risk score, with the Cox partial likelihood as the training objective. It preserves the Cox model's semi-parametric structure (no assumption on the baseline hazard) while gaining expressiveness for non-linear covariate effects. DeepSurv consistently outperforms Cox PH on clinical datasets with heterogeneous patient features (SUPPORT, GBSG, METABRIC). The pycox library provides clean implementations. The limitation is that interpretability degrades: you lose the coefficient-per-feature transparency of Cox PH and must rely on SHAP values applied to the risk score.

DeepHit

DeepHit (Lee et al., 2018) takes a fundamentally different approach: rather than modeling the hazard, it directly models the joint distribution of event time and event type using a multi-task learning architecture. This makes it the natural choice for competing risks — settings where multiple events can occur and the occurrence of one precludes the other. In healthcare: a patient may experience cancer progression, death from other causes, or be censored — these are competing events, and standard survival models that treat non-primary events as censoring produce biased estimates. In insurance: a policyholder may claim, lapse, or expire — three competing outcomes. DeepHit handles all of them simultaneously.

DRSA and Dynamic Survival Models

Dynamic RSA models extend survival analysis to settings with time-varying covariates — where a customer's features change over time (usage levels, engagement scores, support ticket frequency). Standard Cox PH handles time-varying covariates through the counting process formulation, but deep learning approaches like Dynamic-DeepHit can learn complex temporal patterns in covariate trajectories. For subscription businesses that capture monthly feature snapshots per customer, this is the correct formulation — and it substantially outperforms static survival models that only use features at subscription start.

8. Production Use Cases for Survival Analysis

9. Forecasting vs. Survival Analysis: How to Choose

The practical rule of thumb: if your training data contains subjects for whom the event has not yet occurred (still-active customers, still-running machines, still-alive patients), you have right-censored data and should consider survival analysis. Treating censored observations as non-events (binary target = 0) biases the model toward underestimating risk. Dropping them discards information about which subjects are long-surviving — the exact information a churn model should learn from.

10. The Israeli Production Context

MLAIA's experience deploying time series and survival systems in Israel spans several sectors, and the practical realities differ meaningfully from benchmark comparisons:

In telecom and communications (Partner, Bezeq-adjacent analytics), churn modeling involves massive right-censored subscriber bases — over 50% of the population at any snapshot is still active. We routinely apply Cox PH as a first interpretable baseline, then RSF or DeepSurv for uplift. The challenge is time-varying covariates: Israeli telecom subscribers exhibit strong behavioral shifts around IDF service periods, Jewish holidays, and school year transitions — patterns that neither static Cox PH nor a simple GBDT churn model handles naturally without careful feature engineering around these calendar events.

In demand forecasting for retail, the calendar structure is non-standard relative to Western benchmarks: the weekend is Friday-Saturday (not Saturday-Sunday), major holidays (Passover, Rosh Hashana, Yom Kippur) cause sharp demand spikes and drops on dates that shift annually in the Gregorian calendar, and the year has two peak demand seasons rather than one. Prophet's holiday support handles this, but the date conversion logic (Hebrew-to-Gregorian) must be built explicitly. TimesFM and Chronos, trained primarily on Western data, do not inherently model Hebrew calendar seasonality — few-shot finetuning on Israeli series is required.

In medical AI and clinical research (work with Israeli hospitals and MedTech), survival analysis is the standard — clinical trials for medical devices and pharmaceuticals require Kaplan-Meier curves and hazard ratios by regulatory mandate. DeepHit and RSF are increasingly used for secondary analyses and precision medicine personalization, but primary endpoints in regulatory submissions still require Cox PH or Kaplan-Meier.

The 2026 Decision Framework

Three questions to ask at the start of any temporal prediction project:

1. Is the question "how much at time T?" or "when does X happen?" — If the latter, and if some subjects haven't experienced the event yet, start with survival analysis.
2. How many series, and what is your data volume per series? — Under 10k points per series or under 100 series total: Prophet or ARIMA. Thousands of series or rich exogenous features: global LightGBM. Need zero-shot for new series without training: TimesFM or Chronos.
3. What is the forecasting horizon relative to the series length? — Short horizon (1–7 periods): classical or GBDT. Long horizon (30+ periods): N-HiTS, PatchTST, TFT, or foundation model. Very long horizon with multivariate dependencies: TFT or MOIRAI.

Prophet still ships to production every week at organizations that know what they are doing. TimesFM genuinely eliminates the per-series training loop for large-scale forecasting. And survival analysis solves problems that forecasting cannot — not because it is more sophisticated, but because it is the correct model for the data generating process when censoring is present.

The practitioners who build reliable temporal prediction systems in production are the ones who ask which tool fits the problem — not which tool is newest.