TradingView alert fired, then the arrow disappeared

• TradingView Pine Script docs, Repainting
• TradingView Pine Script docs, Alerts
• TradingView Pine Script FAQ, Alerts
• TradingView Help Center, Differences between alert frequencies
• TradingView Help Center, Delays in OncePerBarClose alerts
• TradingView Help Center, Strategy alerts
• TradingView Help Center, Strategy properties, Recalculate
• Nyria docs, Connect TradingView alerts
• Nyria docs, Paper trading
• Nyria FAQ

On a realtime bar, the high, low and close change with every tick. A historical bar keeps only its final open, high, low and close. Your script runs on each tick of the open bar, so a crossover can be true at 10:31:40 and false by 10:32:00. The alert fired at the moment it was true.

When the bar closes, or you reload the chart, the script recalculates from final values. The condition is false there, so the arrow is gone. TradingView's Pine docs define repainting as a script behaving differently on historical and realtime bars, and they note that most built-in indicators do this in a mild form because they read the close.

For an alert on an indicator or a drawing, set Trigger to Once per bar close. The alert then checks the condition when the bar closes and fires only on arrows that stay. TradingView waits for the first trade of the next bar before it treats the close as final, so the alert can arrive a few seconds late, and one minute late when no trade comes at all.

Once per bar fires on the first tick where the condition is true, and the bar can still close false. Once per minute and Every time check while the condition holds, with the same risk on each check. Once only stops after the first fire, whatever happens next.

A strategy alert has no Trigger setting. It fires when the broker emulator fills an order on a realtime bar, so the fix for a strategy sits in the script's own settings, covered two sections down.

barstate.isconfirmed is true only on a bar's last update, when the close is final. Adding it to a condition makes the script act on confirmed values. TradingView's repainting page gives it as the simplest fix:

//@version=6
indicator("Confirmed cross", "", true)
ma = ta.ema(close, 5)
xUp = ta.crossover(close, ma) and barstate.isconfirmed
xDn = ta.crossunder(close, ma) and barstate.isconfirmed
plot(ma)

The same page shows two more ways. Read the condition one bar back with [1], or compute from close[1] so nothing moves mid-bar. Each method shows the arrow later than the repainting version. TradingView says this plainly: you cannot have both immediacy and reliability.

In an alert() call, the freq argument does the same job. alert.freq_once_per_bar_close fires once when the bar closes. The default alert.freq_once_per_bar fires on the first call in the bar, and alert.freq_all fires on every call. Nyria's TradingView docs put it in one line: wrap the call in if barstate.isconfirmed.

A strategy runs once per historical bar, at the close, and by default it runs the same way on realtime bars. With calc_on_every_tick = true in the strategy() call, or Recalculate set to On every tick in Properties, it runs on every price update instead. Historical bars carry no tick data, so the backtest and the live script see different inputs. TradingView's docs say strategies set this way repaint and that their backtest results do not represent live behaviour.

Every fill the emulator makes on a realtime bar fires the strategy alert, including fills that would not exist at the close. Each one reaches your webhook.

TradingView lists two more causes. request.security() reading a higher timeframe whose current bar is still open, and a strategy run on a non-standard chart such as Heikin Ashi or Renko, where fills happen at prices that never traded.

TradingView's docs call "does it repaint" the wrong question and offer specific ones instead:

A practical check takes one session. Let the script run live, then reload the chart. Open the Alert manager and compare its log with the arrows now on the chart. Every alert without a matching arrow is a repaint.

Nyria turns each TradingView alert into an order in your own brokerage account, so a repainting alert becomes a real position. Nyria's setup asks for Once per bar close on indicator alerts and Order fills only on strategy alerts, and tells you to fix a repainting script before the first alert is created. Alert to order, sub-second.

Every alert lands on the strategy's Logs tab with what Nyria read and the order it placed or refused. After a session on paper, compare that tab with TradingView's alert log. A repainting script shows up as orders with no arrow behind them. An identical alert body repeated within 30 seconds is dropped. A script that fires the same message twice in a bar opens one position, not two.

Does Once per bar close fix every kind of repainting?

No. It stops alerts that fire mid-bar on values that later change. It does not fix request.security() calls on a higher timeframe, strategies with calc_on_every_tick, or scripts that draw into the past. TradingView's repainting page covers each one.

Why does my Once per bar close alert arrive seconds after the bar closes?

TradingView waits for the first trade of the next bar before it treats the close as final. On a thin symbol that takes a few seconds. With no trades at all, the server closes the bar one minute after its formal end.

Is a repainting indicator useless?

No. TradingView notes that MACD and RSI fluctuate on the open bar and still have their uses. The problem is acting on an unconfirmed value with real money. Confirm first, then trade.

My strategy's arrows match the backtest. Can it still repaint live?

Yes, if calc_on_every_tick is on or Recalculate is set to On every tick. Historical bars show the close-only version. Live bars run on every tick.

How do I see what an alert sent to Nyria?

Open the strategy's Logs tab. Each alert shows the message as received, how Nyria read it and the order it placed or refused.

What does it cost?

Paper is free. Live trading from $15 a month.