Spotting Repainting: Why an Indicator Looks Better in Hindsight Than Live

Repainting describes an indicator whose values or signals look different in history than they looked in real time. In hindsight an arrow sits neatly at the turning point - live it never appeared there, or only several bars later. For manual chart reading that's an annoyance. For an automated strategy it's fundamental, because a bot only ever sees the real-time version.

Not every change is repainting

On a bar that's still open, practically every indicator changes continuously - a moving average shifts with every tick until the bar closes. That's normal and not a flaw. It becomes a problem only when values on bars that have already closed change after the fact, or when a signal is drawn at a point where it couldn't possibly have been known at the time.

The four typical causes

• Evaluating the open bar: a signal appears during the bar and disappears again before it closes. History only keeps the final version
• Higher timeframe data: while the higher bar is still forming its value keeps changing - but history uses the finished final value straight away
• Confirmation after the fact: a high or low is only recognisable as such once several bars have closed lower or higher afterwards. If the marker still sits on the extreme bar, it precedes its own confirmation in time
• Signals moved or deleted afterwards: markers get recalculated and shifted as the situation changes - only the convenient ones survive in history

Why it invalidates any backtest

A backtest evaluates history - precisely the version that was smoothed after the fact. A bot, by contrast, trades live on the version that was visible at each moment. The gap between the two is exactly what repainting creates. The result isn't a slightly optimistic backtest, it's one describing a strategy that was never tradable as shown. With high and low markers the gap is especially large, because in hindsight the entry sits right at the extreme.

How to check for repainting

• Log signals live for a while - with a timestamp and the bar they appeared on - and compare them against history afterwards
• Replay the past bar by bar if the platform offers a replay function, and note when each signal actually shows up
• For high, low or pivot logic, check how many bars confirmation takes and whether the marker sits on the extreme bar or on the confirmation bar
• A repainting toggle in the indicator's settings is itself a hint that the behaviour is possible

What a non-repainting implementation looks like

The fix is rarely complicated, but it has to be part of the logic from the start: signals are evaluated only on closed bars, higher timeframe values are taken only from that timeframe's last closed bar, and confirmation logic marks the signal where it was confirmed - not where the extreme was. A signal, once triggered, is stored and never altered afterwards. The cost is honestly visible: the signal appears later than a repainting variant suggests in hindsight. But that delay is exactly what happens live anyway.

For how to wire in a higher timeframe cleanly as a filter, see the article on multi-timeframe confirmation.

For what matters when bringing a TradingView indicator across, see the article on porting Pine Script to ATAS.

An indicator that looks too good in hindsight should make you suspicious - not because good signals are impossible, but because history is the one place where repainting stays invisible.