Two columns lead to an additive seasonal forecast
Prophet asks for a dataframe with ds for time and numeric y for the value. From that small input it fits a trend plus yearly, weekly, and daily seasonal effects where the data supports them. Holidays and extra regressors can join the model, and prediction returns yhat, component columns, and uncertainty bounds. Version 1.5.0 keeps the familiar fit-and-predict API in both Python and R.
That simplicity works best for the shape named in the README: strong seasonal effects and several seasons of history. A retail-demand series with weekly behavior and known holidays is a natural candidate. A new product with 6 weeks of erratic observations is not. Prophet is useful because its assumptions are visible in trend and seasonality plots, but a readable decomposition does not make a forecast correct. Historical holdouts still decide that.
The source install exceeded 900 seconds
We cloned commit f931ceb on October 5, 2026 into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The project lived under ./python; the full checkout held 398 files, roughly 7,729 source lines, and used 35.3 MB. Installation did not finish before the 900-second timeout. The supplied result contains no terminal error or log tail, so we cannot attribute the delay to dependency resolution, CmdStan, compilation, or anything else.
The README's development route runs an editable pip install from ./python. By default that process uses a fixed CmdStan version and downloads or installs it when needed. Linux source builders are told to provide gcc, g++, build tools, and Python development headers, with at least 4 GB of memory for installation. PyPI and conda-forge offer easier package routes, but our source result means you should test the exact artifact and base image your jobs will use.
What happened when we ran it
Our sandbox gave the install 900 seconds and it timed out. Since that step never reported success, the measurement block contains no package total and no build or test result. We will not turn the missing results into a failure count. The defensible finding is narrower: commit f931ceb did not complete its documented development installation within 15 minutes on our 3-CPU, 8 GB Debian box.
The checkout scan recorded 2 CI workflow files, no Dockerfile, and no top-level tests directory. Prophet's current Python configuration points pytest at package tests, but our lab did not reach a test result. Nor did it fit a model, measure forecast accuracy, or compare runtimes. The 900-second number describes setup only. Any claim about training speed or prediction quality would need a separate run on an actual series.
Time-series cross-validation is the acceptance test
Prophet includes rolling historical forecasts. You choose cutoff dates, train only on data available before each cutoff, and compare predictions with later observations. The diagnostics cover RMSE, MAE, percentage errors, and interval coverage by forecast horizon. This is the right way to judge the model because a random train-test split leaks future structure into a time-series evaluation. The docs can parallelize cutoffs with processes, threads, or a separately installed Dask cluster.
The same care applies to calendar shape. Prophet automatically fits daily seasonality to sub-daily data, but the guide shows that regular gaps leave unobserved hours unconstrained. If history covers midnight through 6 a.m., predict only that window. Monthly data should produce monthly future rows rather than daily rows between observations. These are model constraints, not formatting details, and they can create wild future movement while the code still runs cleanly.
The default 80 percent interval is not calibrated coverage
Prophet projects future trend changes by assuming their frequency and size will resemble the changes found in history. Its documentation says that assumption is probably untrue and warns against expecting accurate coverage from the default interval. The standard result includes uncertainty from trend and observation noise. Seasonality uncertainty requires full Bayesian sampling with mcmc_samples, which the guide says can take minutes instead of seconds.
Regressors need the same skepticism. Future values must be known or forecast somewhere else. Version 1.4.0 added nested Prophet models for unknown regressors, but only simple nested models are supported. They cannot have their own extra regressors or custom seasonalities. Forecast error in an upstream regressor can then flow into the main prediction, so cross-validation must reproduce the whole chain rather than substitute future values that would not be known in production.
Maintenance mode still produced v1.5.0 fixes
The README says Prophet entered maintenance mode at v1.4.0, with bug fixes, dependency updates, and R parity work accepted but no new features planned. That is a product boundary, not abandonment. GitHub showed a push on October 5, 2026, and v1.5.0 shipped that day with cross-validation, metric-mutation, constant-history, and import fixes. The repository had 20,429 stars and 448 combined open issues and pull requests.
The queue is large enough that you should search your deployment shape before upgrading. Reports active in 2026 include a development install looking for libtbb2 on Ubuntu 24.04 and a Prophet 1.1.6 binary segfaulting in a Python 3.12 container. Those reports do not prove v1.5.0 has the same faults. They do show why a successful fit belongs in your image test, especially after our own f931ceb source install exhausted 900 seconds.
Prophet remains a sensible baseline when seasonality, holidays, and trend changes describe the business problem. Our run does not support calling its source setup easy, and the project no longer promises feature expansion. Start with a pinned package, replay historical cutoffs at the horizon you care about, and inspect failure periods such as promotions or lockdowns. Keep it only if those errors beat a simpler seasonal baseline.