Pine Script Alert Repainting Mistakes: Why Signals Change After They Fire

Pine Script alerts usually fail live when the plotted signal, alert condition, realtime candle state, and higher-timeframe data are not designed as one system.

One of the most common searches in Pine Script is some version of this problem: the signal was visible on TradingView, the alert fired at a different time, and after a reload the chart no longer agrees with what happened live. That is not a small cosmetic bug. If the script controls webhook automation, it can become a real execution problem.

Why this happens

Pine Script runs differently on historical bars and realtime bars. Historical bars are already closed, so the script sees finished candles. Realtime bars move tick by tick before the candle is confirmed. If the alert uses a condition that becomes true during the open candle and then disappears before close, the trader remembers the alert, but the chart may not show the same signal later.

The professional fix is not to hide the issue. I like to expose it. I separate raw conditions from confirmed conditions, plot both while debugging, and decide which one the trader actually wants. Some scalpers intentionally use intrabar logic. Most automation clients do not. They want the signal that survives candle close.

//@version=6
indicator("Confirmed alert pattern", overlay = true)

fast = ta.ema(close, 20)
slow = ta.ema(close, 50)
rawBuy = ta.crossover(fast, slow)
confirmedBuy = rawBuy and barstate.isconfirmed

plot(fast, "EMA 20", color = color.teal)
plot(slow, "EMA 50", color = color.orange)
plotshape(rawBuy, "Raw buy", shape.circle, location.belowbar, color = color.gray, text = "raw")
plotshape(confirmedBuy, "Confirmed buy", shape.triangleup, location.belowbar, color = color.lime, text = "BUY")

alertcondition(confirmedBuy, "Confirmed buy", "BUY {{ticker}} close={{close}} time={{time}}")

The mistakes I see in client scripts

• The alert condition is not the same condition that plots the visible signal.
• The trader updates the code but forgets to recreate the TradingView alert snapshot.
• The script uses higher-timeframe data without a clear non-repainting policy.
• The strategy uses tick recalculation, but the trader compares it with closed-bar backtests.
• The alert message is too vague to debug after the order is sent.

When I audit this for a client, I do not only ask for the code. I ask for the alert screenshot, the alert message, the timeframe, and a chart example where the problem happened. That gives enough context to tell whether it is repainting, alert frequency, higher-timeframe data, or a webhook misunderstanding.

How I would rebuild it

I start with a simple rule: the alert should be boring. It should say exactly what happened, on which symbol, at which price, and which version of the logic created it. If a bridge or broker receives the message, the message should be useful without opening TradingView.

For serious automation, I also add state checks. If the script has already fired a long signal, it should not keep firing repeated long messages unless that is intentional. If the script has a cooldown or session filter, that filter should be visible in the debug panel. Good Pine code tells the truth about itself.

This is the kind of repair work Jayadev Rana handles often: not just making a signal appear, but making sure the signal can be trusted by a human, an alert system, and an execution bridge.

The best Pine Script repairs are not dramatic. They are disciplined. Confirmed signals are separated from raw signals. Higher-timeframe data is handled intentionally. Alerts are recreated after code changes. The final script has enough visible debug information that a trader can trust what happened on the chart.

For webhook automation, I add one more standard: the alert must be auditable after the fact. If a trader sends me a broker log and a TradingView alert log, I should be able to match the event without guessing. That means the alert message should include the ticker, action, price, bar time, and strategy version or setup name. Pretty messages are less important than useful messages.

I also check how the script behaves when the market is quiet. Bad alert logic often looks fine during a strong trend because every signal seems obvious. The real test is sideways movement, candle wicks, session open volatility, and higher-timeframe candles that are still forming. Those are the places where repainting complaints usually come from.

My final check is always practical. I run through a few examples bar by bar and ask whether the script, the plotted label, the alert condition, and the message all describe the same event. If one of those layers is different, the trader will eventually feel that the script is lying, even if the math is technically doing what the code says.

What I check before I call an alert reliable

Ask Jayadev Rana to check your repainting or alert issue on WhatsApp

Frequently asked questions