Why 'Once Per Bar Close' Alerts Still Fire Late

You set the alert to "Once Per Bar Close" on purpose, specifically so a live, still-forming candle couldn't trigger a false signal on you. The candle closes. Your phone stays quiet for six seconds, then twelve, and by the time it buzzes the

You set the alert to "Once Per Bar Close" on purpose, specifically so a live, still-forming candle couldn't trigger a false signal on you. The candle closes. Your phone stays quiet for six seconds, then twelve, and by the time it buzzes the next candle is already a third of the way built. Nothing is broken and nothing mis-fired. TradingView's own support documentation describes exactly why this happens, and the mechanism has nothing to do with your internet connection or your broker's plumbing. "Once Per Bar Close" doesn't mean "the instant the bar closes." It means "once TradingView is confident the bar closed and is staying closed," and that confidence check is where the delay you're feeling actually lives.

The alert isn't lying to you about when the bar closed

On a historical chart, a bar is a fixed, finished thing: open, high, low, close, done. TradingView's own Pine Script FAQ on alerts draws a sharp line between that and a live bar, stating that on historical bars a script "executes once per bar close," while on realtime bars, where alerts actually fire, the same script "executes once for each new tick from the data feed." A live bar isn't a value. It's a value that keeps getting overwritten until something tells the platform to stop.

That's the same distinction behind why a strategy tester result can look nothing like the trade you'd actually get live: historical and realtime data are two different animals wearing the same chart. "Once Per Bar Close" is TradingView's attempt to make the live animal behave like the historical one before it lets your condition fire, and that attempt is where the delay comes from.

TradingView waits for proof the old bar actually finished

Here's the part that isn't guesswork. TradingView's own support article on the topic states the mechanism directly: "To determine whether the current bar has actually closed, the server waits for the first trade of the new bar." No confirming trade, no fired alert, even though your chart visually rolled over the second the clock hit the close.

The reason isn't arbitrary caution. A trade can still be in flight when a bar's formal close time arrives, and firing the alert before that trade settles risks alerting on a price the exchange hasn't finished writing yet. Waiting for the first tick of the next bar is TradingView's proof that nothing late is still landing on the bar you're closing out.

That proof isn't free when the market goes quiet. The same article describes the fallback: "if there are no trades for too long (for example, after a session closes), the server automatically 'closes' the current bar 1 minute after its formal close," rather than waiting indefinitely for a confirming trade that may not come. A session lull doesn't break the mechanism. It walks the mechanism straight into its own timeout.

"Once Per Bar" and "Once Per Bar Close" are two different bets

TradingView's alert() function takes a frequency argument, and the same Pine Script FAQ names the two relevant options directly: alert.freq_once_per_bar and alert.freq_once_per_bar_close. They are not a fast setting and a slow setting. They're two different answers to the question of what you're willing to act on.

"Once Per Bar" fires the moment your condition is true on a fresh bar, using whatever data exists on that bar right now, which can still change before it closes. "Once Per Bar Close" refuses to fire until the confirmation check above has run. It's the difference between calling a store to ask if it's open and getting an answer the instant someone picks up, versus getting an answer only once someone's actually walked to the door and checked. Both answers are honest. They're just answering different questions.

Every "my alert is delayed" complaint we've dug into turned out to be a complaint about which kind of certainty the trader actually asked for.

— The Tradoki desk note

The webhook relay is almost never where the delay hides

Traders who automate alerts into a broker through a relay service tend to point at the relay first when a fill lands later than expected. The vendor data doesn't support that instinct. CrossTrade, which relays TradingView webhooks into NinjaTrader, publishes its own numbers: an average of 34 milliseconds from webhook receipt to delivering the validated order, based on "hundreds of thousands of daily webhook executions" across its user base, covering TLS handling, authentication, and message delivery.

CrossTrade's own account of where the real time goes is the more useful part. The full chain, by its account, runs on TradingView's dispatch time first, then the relay, then the broker's order processing, with its 34-millisecond link being "the smallest component of that chain." The confirmation wait built into TradingView's own alert engine, not the third-party pipe carrying the alert onward, is doing most of the work you're feeling as lag.

Thin markets and news spikes pull the wait in opposite directions

The confirmation mechanism depends on a real trade printing on the new bar quickly. On a liquid instrument during normal hours, that first trade usually shows up within a moment of the close, so the alert lands close behind it. On a thin instrument, or during a session lull, no trade may print for a while, walking the alert straight toward the one-minute timeout described above.

Scheduled news releases sit at an odd crossing point of that logic. Liquidity providers pull resting orders in the seconds around a major print, which is the same liquidity gap that governs how prop firms restrict news trading in the first place. Volume is high in that window, so a confirming trade usually arrives fast, but the price it confirms can already sit several ticks from where the bar looked like it was closing when you last glanced at the chart.

Pick the setting that matches the guarantee you actually need

None of this is a case for abandoning "Once Per Bar Close." For anything that reacts to a signal rather than executing at a fixed instant, a confirmed value beats a fast, unconfirmed one every time, which is the same logic behind wrapping a Pine condition in barstate.isconfirmed before treating it as real. The setting is doing its job when it's a few seconds behind your chart.

Where it stops being the right tool is anything that needs to race a clock rather than confirm a value, in the same way a plain stop-market order and a price-bounded stop order solve two different problems and aren't interchangeable. If the requirement is genuinely sub-second execution on a fixed schedule, that belongs in order-management tooling built for it, not in an alert condition that was designed to wait until it's sure.

● FAQ

Why does my TradingView alert fire a few seconds after the candle closes?

Because 'Once Per Bar Close' isn't a promise about instant delivery. Per TradingView's own support documentation, the server waits for the first trade of the new bar to confirm the old one is really finished before it evaluates your condition. On a thinly traded instrument, that confirming trade can take several seconds to print, and the alert waits with it.

What is the difference between 'Once Per Bar' and 'Once Per Bar Close' on TradingView?

'Once Per Bar' fires the first time your condition is true after a new bar opens, using whatever data exists on that still-forming bar. 'Once Per Bar Close' waits for TradingView's confirmation check described above. One trades speed for a value that can still change; the other trades a few seconds of delay for a value that won't.

Does a slow webhook or automation service cause TradingView alert delay?

Usually not, and vendor data backs this up. CrossTrade's own published benchmark puts its webhook-to-NinjaTrader relay at an average of 34 milliseconds across hundreds of thousands of daily executions, and the company states plainly that the biggest variable in the full chain is TradingView's own dispatch time, not the relay sitting in the middle.

Is there a maximum delay on a TradingView alert?

There's a documented floor, not a ceiling. If no new trade prints at all after a bar's formal close, TradingView's server automatically closes that bar on a one-minute timeout rather than waiting indefinitely for a confirming trade. Extended illiquidity or a session lull is exactly when that timeout gets used.

Should I use TradingView alerts for a strategy that needs precise entry timing?

Not if 'precise' means sub-second. Once Per Bar Close is built to confirm a value, not to race the clock, and no combination of settings on TradingView's side turns it into a zero-latency signal. If timing precision is the actual requirement, that belongs in your broker's own order tools, not in an alert condition.