The script is using information that behaves differently on open realtime bars and confirmed historical bars. Identify every unconfirmed value and higher-timeframe request, then decide whether the tool should wait for confirmed data or explicitly disclose realtime variation.
What you may be seeing
- Signals move or disappear after refreshing the chart
- Historical plots look different from what you saw live
- An indicator appears accurate in history but changes on the realtime bar
Most likely causes
- The script uses information that is not confirmed until a realtime bar closes
- Historical and realtime executions receive different information
- Higher-timeframe or other requested data is used before it is confirmed
Try this first
- Identify which values can change during the open realtime bar
- Where appropriate, require confirmed-bar information before accepting a signal
- Review request.security or other timeframe requests for repainting behavior
- Reload and compare the script again before relying on the signal
If that didn’t fix it
- Use barstate.isconfirmed when waiting for a closed realtime bar is acceptable
- For alerts, consider triggering only after the bar closes
- Document intentional repainting if the script is designed to use live intrabar information
Verify the fix
Watch the indicator through a realtime bar, note its signal, then reload after that bar closes. The historical result should remain consistent with the confirmed logic you intended.
Why this happens
The script is using information that behaves differently on open realtime bars and confirmed historical bars. Identify every unconfirmed value and higher-timeframe request, then decide whether the tool should wait for confirmed data or explicitly disclose realtime variation.
Repainting is not one single bug. It can come from fluid realtime prices, future-leaking higher-timeframe requests, calculations that do not run consistently, or intentional plotting into the past.