← Changepoint Detector · FREE · RUNS IN YOUR BROWSER · NOTHING UPLOADED
How do you know if a time series really changed?
Sign-ups dipped after the redesign. Latency looks higher since Tuesday's deploy. The sensor reads warmer since it was moved. Is that a real shift, or the noise you see every week? A chart can't tell you. Changepoint detection can: it asks whether your data are better described as two segments than one, after charging a penalty for every extra segment, and says when the change happened and how sure to be.
Who this is for
Product and growth analysts
Did conversion really move after the launch, or did you pick the before-and-after dates that make it look that way?
Engineers and SREs
Did p95 latency or error rate step up at a deploy, and from which build? A lasting shift, not one spiky minute that an alert already caught.
Scientists and engineers with sensor data
When did the instrument drift, the flow drop or the regime change, with a method you can cite in a paper?
Anyone counting things
Orders, incidents, visits per day. Counts have their own model here, with options for weekly cycles and clumpy days.
Why the obvious ways mislead
- Eyeballing the chart. Quick, but noise has runs in it. Your eye finds a step in almost any series and cannot say whether it would survive more data.
- Comparing the average before and after the date you suspect. You picked the date by looking at the chart, so a test at that date is biased toward finding a difference. A changepoint method searches every split point and pays for the search.
- A rolling average. It smooths the noise and smears the change across the window, so it lags and blurs the date.
- Anomaly alerts. They flag single odd points. A lasting change in level is a different question.
A worked example: the Nile, 1871 to 1970
The annual flow of the Nile at Aswan is the classic test series for this question; Cobb (1978, Biometrika) placed its change around 1898, the year the first Aswan dam was begun. Load it on the tool with one click. This is what the tool reports (output of node cli.mjs --example):
| Segment | Years | Mean | SD |
|---|---|---|---|
| 1871 – 1898 | 28 | 1097.75 | 135.0 |
| 1899 – 1970 | 72 | 849.97 | 124.8 |
One change, from 1899: the mean drops by about 248, which is 2.15 noise standard deviations. The Bayesian method puts 79% probability on a change within 3 points of it, and no other year reaches 50%. R's changepoint package gives the same split (cpts = 28). Two independent methods and the literature agree, which is what a real change looks like.
Three traps that fake a change, and what the tool does about each
Both methods assume the noise around each level is independent and the level is flat. Real series often break that, and each break shows up as extra, false changes. The tool's test suite measures each trap on seeded synthetic series (the numbers are from the README's Verification section):
| Trap | Without the option | With it | Option on the page |
|---|---|---|---|
| Sticky noise (each point like the last; AR(1), rho 0.8, no change) | false change in 40 of 40 runs | 4 of 40 | "Autocorrelated noise: allow for it" |
| A seasonal cycle hiding a real step of 4 (period 12) | exactly one change, at the step: 0 of 40 | 33 of 40 | "Seasonal period in points" |
| A steady ramp with no change | 5.5 false changes per series | 0.15 | "Level or slope (trending series)" |
The corrections cost some power on small shifts; the README states by how much. If your series has a weekly or monthly rhythm, a trend, or tends to stay high once it is high, switch on the matching option before you believe a result.
What you get
- PELT (Killick, Fearnhead & Eckley 2012): the exact best segmentation under a penalty per change. Not a heuristic.
- Bayesian online changepoint detection (Adams & MacKay 2007): a probability that a new segment began at each point.
- Models for a change in level, in level and volatility, in slope, and in the rate of counts (with seasonal, trend and overdispersion options).
- A chart, a table of changes and segments, and a per-point CSV download.
- The same engine as a zero-dependency command-line tool and as a tool AI agents can call. MIT licence, source on GitHub.
When to use something else
For many series at once, multivariate data, very long series or a production pipeline, R's changepoint package and Python's ruptures are the reference tools and more complete. This page is for the one-off question on one series, without setting up an environment. On 100 seeded test cases its PELT returned the same changepoints as ruptures on all 100.
Find the changepoints in your own series
Questions
How do you know if a time series really changed?
Ask whether the data are better described as two or more segments with different levels than as one, after paying a penalty for every extra segment. That is changepoint detection. PELT finds the best segmentation exactly; Bayesian online changepoint detection gives a probability for a change at each point. A change both methods agree on is strong evidence; a change only your eye sees usually is not.
Why not just compare the average before and after the date I suspect?
Because you picked the date by looking at the chart. Choosing the split point from the data and then testing at that point makes a difference look far more significant than it is. Changepoint detection searches every split point and charges for the search, so it does not have that bias.
What makes a changepoint detector report changes that are not there?
Three things, mainly: autocorrelated noise (each point resembles the one before), a seasonal cycle, and a steady trend. Each looks like a series of steps to a method that assumes independent noise around a flat level. Measured on seeded series in this tool's test suite: sticky noise with no change at all produced a false change in 40 of 40 runs uncorrected and 4 of 40 with the autocorrelation option; a pure ramp produced 5.5 false changes per series with the level model and 0.15 with the trend model.
Does a changepoint prove the release or price change caused it?
No. It says when the data changed and by how much. Whether your release, a holiday or an outage caused it is a separate question that needs what you know about that date.
Should I use this tool or R or Python?
For a one-off question on one series, this page is quicker: paste a CSV, no install. For many series, multivariate data, costs this tool lacks or a pipeline, use R's changepoint package or Python's ruptures, which are more complete. This tool's PELT matched ruptures on 100 of 100 seeded test cases.
Is my data uploaded?
No. The tool reads and analyses the file in your browser tab. Nothing you paste is sent anywhere.