Repainting indicators: what repainting is, how to detect it, and why it fakes a backtest

By John, builder of Wise Apple · Updated August 27, 2026

The indicator nailed every top and bottom for the last two years. You scrolled back and checked. Then you traded it for a week and it caught nothing — and when you looked again, the signals from that week had moved.

That is repainting, and it is the most common reason a chart looks like a crystal ball and trades like a coin flip. It is also the reason "I backtested it on the chart" is not a backtest. The chart you scrolled through was drawn with knowledge of what came next. The trades you took were not.

This guide covers what repainting actually is, the three different mechanisms that get called by the same name, a test you can run on any indicator in five minutes, and how to keep using the ones that repaint without letting them into your backtest.

What repainting means

An indicator repaints when the value it shows for a past bar is different from the value it showed when that bar was the current one. The signal at 10:00 on Tuesday was not there at 10:00 on Tuesday. It appeared on Wednesday, once the indicator knew how Tuesday ended, and the chart drew it back in time as if it had always been there.

This is data leakage with a picture. The indicator is using information from after the bar to decide what to show on the bar. Any backtest built on those values inherits the hindsight.

The three kinds of repainting

"Repainting" is used for three mechanisms that behave differently and need different fixes. Knowing which one you have matters.

1. The unclosed-bar flicker

Most indicators compute on the current bar while it is still forming. The close changes tick by tick, so the indicator's value changes tick by tick, and a signal can appear at 10:03, vanish at 10:07, and come back at 10:12. Once the bar closes, the value is final and never changes again.

This is the mild kind. It is not hindsight — it is the honest uncertainty of an unfinished bar. The fix is a rule, not a code change: act only on closed bars. If you take the 10:03 signal and it vanishes, you took a trade the closed-bar version of the strategy would not have taken, and your results will not match your backtest.

2. The centred window

Some calculations need bars on both sides of the point they are describing. A pivot high is a bar that is higher than the N bars before it and the N bars after it — so it cannot be confirmed until N bars later. Zigzag lines, swing detectors, fractals, and most "smooth" filters that average symmetrically all work this way.

Plotted historically, they are perfect, because they were drawn with the future in hand. Live, the pivot appears N bars late, by which time the move it marks is over. Some implementations quietly redraw the last N bars when each new bar arrives; the historical plot shows the redrawn version. This is the kind that makes a backtest lie.

The fix is to shift the signal to the bar where it was actually confirmed — N bars after the pivot — and accept that the confirmed version is a different, less impressive indicator.

3. Timeframe and data leaks

An indicator on a 1-hour chart that pulls a value from the daily timeframe can receive the daily bar's close before the day is over — which means it knows, at 11:00, where the day closed. Some charting platforms also compute historical values from a different data feed than the live one, or from the highs and lows of finished bars when the live version only sees closes. Historical and real-time paths differ, and the historical path knows more.

The fix is to request higher-timeframe values only after that bar has closed, and to confirm the indicator's historical and real-time calculations follow the same path. This one is hard to see from the outside, which is why the test below matters.

The five-minute test

You do not need to read the code. You need a chart with a replay feature and a notepad.

1. Pick a stretch of history with a dozen signals on it. Screenshot it.
2. Rewind the chart to before that stretch and play it forward one bar at a time.
3. Each time a signal appears, write down the bar it appeared on and the bar it points at. If those are different bars, you have found a centred window.
4. Finish the replay. Compare the signals you logged to the screenshot. Any signal in the screenshot that was not in your log, or that sits on a different bar, is repainting.
5. For the timeframe leak: do the same on a chart that uses a higher-timeframe value, and check whether the value changes before that higher bar closes.

The honest version of a strategy is the one in your log, not the one in the screenshot. If you backtest anything, backtest the log — and backtest it with the costs charged, because a repaint-free strategy with tiny targets is the next thing that breaks.

Why this fakes backtests specifically

A backtest takes an indicator's historical values as given. If those values were computed with a centred window, every entry is placed at the ideal bar — the actual low, the actual high — and the report shows a win rate no live trader will ever see. The cruel part is that the backtest is consistent: run it twice, get the same beautiful answer. Consistency is not honesty.

The fails-live guide lists this as the first cause to rule out, because its fingerprint is distinctive: the strategy is broken from day one, not degraded, and delaying every signal by a few bars destroys it.

Keeping indicators that repaint

You do not have to throw them out. Pivots, swings, and smoothed filters are useful descriptions of the past. What you cannot do is let their historical values into a decision. Two honest uses:

• Use the confirmed version. A pivot confirmed 5 bars late is still a pivot. Build the rule on the confirmed value and let the backtest be as unimpressive as the truth.
• Use them for context, not signals. A zigzag that tells you where the last swing was is fine as a chart annotation. It is not fine as an input to a rule that fires on it.

Writing an indicator that does not repaint

If you write your own indicators, four habits prevent nearly all of it. Compute only from closed bars — reference the previous bar's close, never the current bar's. Never use a window that extends past the current bar; if a calculation needs future bars to confirm, delay its output until those bars exist and plot it at the confirmation bar. Request higher-timeframe values only for the last completed higher-timeframe bar. And test the historical and real-time paths against each other with the replay test above, because an indicator that is correct in principle can still be implemented with a shortcut that is not. The full backtesting guide treats leak-checking as its own step for this reason.

Where this sits in Wise Apple

Every feature Wise Apple feeds to a model is computed on closed bars, and fills are scheduled for the bar after the decision, so a signal cannot act on a bar it has not finished seeing. WiseApple Script indicators evaluate the same way in the studio, in the browser worker, and on the Alert Node, which removes the historical-versus-real-time split that causes the third kind of repaint. The experimental training-wheels mode exists precisely so you can leak a few future candles on purpose and watch a strategy's report turn from honest to prophetic — reports made that way are stamped and never reach an alert.