Why Are TradingView Alerts Delayed? Bar Close, Webhooks, Fixes

A delayed TradingView alert is often working as designed: a Once Per Bar Close alert (one that fires only after the bar has finished) waits for the first trade of the next bar, so on a 5-minute chart it lands at least 300 seconds after the time printed under the bar. Genuine faults are narrower and show in the alert log: a receiver slower than the 3-second webhook timeout, a wrong port, an alert stopped after more than 15 triggers in 3 minutes, or an expired alert. On futures, free CME data can add a quieter 10-minute lag.

Key takeaway

According to TradingView's Help Center, a Once Per Bar Close alert waits for the first trade of the new bar, and after a session close with no trades it fires 1 minute late. Bars are labelled by their opening time, so the minimum label-to-alert gap is 60, 300, 900 or 3,600 seconds on 1, 5, 15 and 60 minute charts. Delivery faults show in the alert log: a receiver that misses TradingView's 3-second webhook timeout or returns an error, or a documented limit that stops the alert.

Why does my TradingView alert fire after the candle on the chart?

Because the time under a TradingView bar is the moment that bar opened, not the moment it closed. The Pine Script manual on time says "The time variable holds the UNIX timestamp of the current bar's opening time", so a 5-minute bar labelled 09:30 runs from 09:30:00 to 09:34:59 (illustrative times).

A Once Per Bar Close alert must wait for that bar to end, and TradingView does not trust the clock to say when. Its Help Center page on OncePerBarClose delays explains: "To determine whether the current bar has actually closed, the server waits for the first trade of the new bar." The earliest firing is 09:35:00, 300 seconds after the label.

Once Per Bar fires the first time the condition is true while the bar is still forming. Picture the bar as a ruler from 09:30:00 to 09:35:00: the condition turns true at 09:31:12, 72 seconds in, and Once Per Bar fires there, while Once Per Bar Close fires at 09:35:00 or later, 228 seconds behind it. Depending on when the condition turns true, the extra wait runs from 1 second to 300 seconds.

The label marks when the bar opened, so a bar-close alert is always at least one bar behind it; Once Per Bar fires earlier, on a condition that can still change.

TradingView's Help Center says Once, Once Per Minute and Once Per Bar alerts on indicators can trigger while the bar is still building, for example on an RSI that dips through 30 and climbs back before the close. You are choosing between speed and a signal that cannot change after it fires.

The gap between the printed label and the earliest Once Per Bar Close alert is one full bar on every timeframe, as the table shows.

Chart	Bar labelled	Last second	Earliest alert	Label-to-alert gap
1 minute	09:30:00	09:30:59	09:31:00	60 s
5 minutes	09:30:00	09:34:59	09:35:00	300 s
15 minutes	09:30:00	09:44:59	09:45:00	900 s
60 minutes	09:30:00	10:29:59	10:30:00	3,600 s

Computed by Phoenix Technologies; method: earliest alert = label + bar length in seconds, from TradingView's rules that labels mark the open and the next bar's first trade confirms the close. These are minimums; the real time adds however long that trade takes.

An alert stamped 10:30:00 for the hourly bar labelled 09:30 is on time, not an hour late.

The minimum gap is exactly one bar on every timeframe, so an hourly alert stamped an hour after its label is on time.

Why does a Once Per Bar Close alert arrive seconds or a minute after the close?

Because the close is confirmed by the next trade, and that trade can be late or never come. On a rarely traded instrument, or during technical delays, TradingView says the first trade of the new bar "may appear several seconds after the bar formally closes". It gives no number for "several", and no public data does.

When no trade arrives at all, the server closes the bar itself 1 minute after its formal close. TradingView's own example: "Therefore, for example, an alert for a session close will not trigger exactly at the close, but 1 minute after."

Take the last 1-minute bar of a session (illustrative times). The bar labelled 15:59:00 reaches its formal close at 16:00:00; no trade follows; at 16:01:00 the server closes the bar and the alert fires, 60 seconds after the close and 120 seconds after the label.

With no next trade to confirm the close, TradingView waits a fixed minute before closing the bar itself, so session-close alerts are late by design.

The same rule explains alerts that sleep through a closed market. The Pine Script Alerts FAQ notes that a closed market has no price updates, so an alert with a delay will not fire until it reopens: scripts run on ticks. Telling a quiet market from a broken one is covered in spotting stale or dead data.

Why do strategy alerts fire later than the strategy tester shows?

A default strategy only calculates at bar close, and the tester redraws historical fills at the bar's open time. Neither is a delivery delay.

The Pine Script manual on alerts says that in a strategy without calc_on_every_tick, "all alert() calls will use the alert.freq_once_per_bar_close frequency, regardless of the argument used for freq." Its next possible fill is the open of the following bar.

The second is a display artefact. TradingView's page on strategy alert trigger times says "For historical orders (i.e., orders executed before the chart page was opened), the order execution time is the open time of the corresponding bar." In its example a live alert fires at 09:23 UTC; after a refresh the tester shows the trade at 09:00, an apparent 23-minute delay (1,380 seconds) that never happened.

TradingView also lists calc_on_every_tick, calc_on_order_fills and trailing orders as causes of mismatch between alerts and chart orders. The wider gap between simulated and live fills is explained in why sim results differ from live.

Can delayed market data make TradingView alerts late on futures?

Likely yes, by about 10 minutes, if your CME symbol shows TradingView's free data. According to TradingView's CME page, as of October 2026, "All CME Group's data is available for free on TradingView with a 10-minute delay."

An alert runs on a saved copy of the chart's symbol and timeframe, so it sees what that symbol sees. TradingView does not state that an alert on a delayed symbol evaluates delayed data; that is our inference from those two documented facts, and we found no published test of it.

Run the same 5-minute Once Per Bar Close alert on two charts of one contract, one per feed. On real-time data the earliest alert is 09:35:00, 300 seconds after the label. On the delayed feed TradingView sees that bar close at 09:45:00: 900 seconds after the label, 600 seconds later, two full 5-minute bars.

On TradingView's free CME data the same alert most likely fires two bars later, by our inference from TradingView's documentation; the cause is the feed, not the alert engine or the network.

Check this before blaming anything downstream. TradingView's Help Center says delayed symbols in alerts carry a "D" marker, and the exchange prefix appears only in the alerts manager. Because an alert keeps the symbol it was created on, recreate it after subscribing. Subscription options are in our guide to real-time futures data options, and feed differences in chart versus broker price gaps.

What happens between the alert firing and the order reaching the broker?

TradingView sends a webhook (an HTTP POST carrying your alert message) to your URL; your receiver must answer within 3 seconds and then carries the order to the broker. TradingView documents the waits and limits on this path but publishes no figure for its own dispatch speed.

Stage	What sets the time	Documented figure
1. Condition true on a realtime bar	Trigger mode	Once Per Bar: at once; Once Per Bar Close: not before the next bar opens
2. Bar-close confirmation	First trade of the new bar	"Several seconds" on thin instruments; 1 minute after the close if no trade
3. Data delay	The symbol's feed	10 minutes on free CME data (inferred for alerts)
4. TradingView dispatch	TradingView's servers	Not published
5. Receiver answers the POST	Your server, bridge or copier	Within 3 seconds or cancelled; retries not published
6. Receiver to broker	Receiver and broker API	Not published by TradingView; vendor figures unaudited

Compiled by Phoenix Technologies from TradingView's Help Center and Pine Script manual, accessed October 2026. Stages 1 to 3 carry the documented waits of seconds to minutes, and all three live on your chart, not in the network.

A slow receiver does not just add delay. TradingView's webhook configuration page says "If a remote server takes longer than three seconds to process a request, the request will be cancelled." It does not say whether a cancelled request is retried, so treat a timeout as a lost order until your logs prove otherwise.

The path runs from condition true through TradingView's alert engine and the POST leaving on port 80 or 443 to your receiver with its 3-second clock, then the broker; the receiver is the one valve that can shut. A side counter stops the whole alert after more than 15 triggers in 3 minutes, and the alert log's "Webhook status" column records what happened at the valve.

TradingView documents the limits along the path but not its own speed; the one hard deadline, 3 seconds, belongs to your receiver.

The same page sets the entry conditions: ports 80 and 443 only, no IPv6, 2-factor authentication required, and four published sending IP addresses that a firewalled receiver must allow. The webhook error reference lists timeouts, TLS failures, rejected connections, private addresses and 3xx to 5xx responses, and says: "Most errors are related to the receiving server."

All of this applies whatever receives the webhook: your own script, a bridge, or a copier such as Thor. Later stages are broken down in our copy trading latency budget, plan choices in TradingView for futures trading, and firm limits in prop firm automation rules.

How fast are TradingView webhooks?

TradingView publishes no figure for the time between a condition turning true and the webhook leaving, so the only reliable number is one you measure. Its introduction to alerts says only that alerts run on its servers, "ensuring fast and stable performance", and the webhook page warns they "may occasionally fail to reach the specified URL", with no failure rate given.

The figures that circulate have no source. ClearEdge Trading's guide says "Most delays range from 100-500 milliseconds under normal conditions, but can spike to 2-5 seconds during high-volume periods", and elsewhere on the same page gives 100 to 300 ms. PickMyTrade's FAQ claims spikes of 25 to 45 seconds around FOMC, also unsourced.

ClearEdge also lists Once Per Bar Close among its fixes, on the grounds that it cuts server load; on a 5-minute bar that setting fires 1 to 300 seconds after Once Per Bar would. To measure the delay yourself, put {{timenow}} (the alert's fire time in UTC, to the nearest second, per TradingView's Help Center) in the alert message and compare it with your receiver's arrival time on a synced clock.

Why did my TradingView alert stop firing or never trigger?

Five documented causes can silence an alert: the trigger limit, expiry, an old copy of your script, a runtime error, or repainting.

Trigger limit. TradingView's page on alerts triggered too often, as of October 2026, allows regular alerts "no more than 15 triggers in 3 minutes", and watchlist alerts 1,000 in 3 minutes overall. That averages 5 per minute, one every 12 seconds, but it is a burst window: 15 triggers in 10 seconds are fine, and the 16th stops the alert. Broker-side throttling is covered in API rate limits for automation.
Expiry. TradingView's Help Center says a standard alert lasts at most two months, with an open-ended option on some plans, and deactivates alerts over a year old with no trigger and no edit for a year. Its pricing page reads differently, so check the expiration field in the alert dialog.
Old snapshot. On creation, the Pine manual says, TradingView "saves a mirror image of the script and its inputs, along with the chart's main symbol and timeframe". Editing the script changes nothing until you recreate the alert.
Runtime error. An error such as a loop running past the 500 ms limit in the Pine Script Alerts FAQ stops the script, and the alert with it.
Repainting (a script behaving differently on history than in real time). Alerts trigger only on realtime bars, so a signal painted on history may never have fired live.

CrossTrade's FAQ says TradingView limits alerts to "reportedly around 3 per minute on most plans". That would mean 9 triggers in 3 minutes; TradingView's documented 15 contradicts it.

Repainting is the norm. The Pine manual on repainting estimates that "more than 95% of indicators in existence exhibit some form of repainting behavior". A history-dependent script also drifts on the server: TradingView's Help Center page on repainting and alert calculation says "the alert is calculated continuously on the server, so after the alert is launched, the number of bars involved in its calculation only increases." Recreate such alerts periodically.

How do I tell a design delay from a real fault?

Compare the bar's close, the alert log time and your receiver's log for the same signal: a gap that matches the tables above is design, and anything else is a fault the alert log usually names. For a 5-minute Once Per Bar Close alert on the bar labelled 09:30:

Earliest legitimate time: 09:30:00 plus 300 seconds is 09:35:00.
Read the alert log. At 09:35:00 or seconds after, TradingView did its job. At 09:45:00 or later on a CME symbol, look for the "D" marker: the 600-second data delay.
Read the "Webhook status" column. "Timeout exceeded" means your receiver took longer than 3 seconds.
Check the receiver's log. Nothing there while TradingView shows a send points to the port, the IP allowlist or a private address.
Compare the receiver's time with the broker's fill time, with both clocks synced; see keeping your clocks in sync.

Symptom	Cause	What to do
Alert one bar after the chart label	Labels mark the bar's open	Nothing, or Once Per Bar if intrabar signals are acceptable
Seconds after the close, thin contract	Waiting for the next bar's first trade	Nothing; expected
Session-close alert 1 minute late	Server closes an idle bar after 1 minute	Nothing; expected
About 10 minutes late, CME symbol	Delayed data ("D" marker)	Real-time data for that symbol, then recreate the alert
Tester shows the trade earlier	Historical fills drawn at bar open	Judge by the live alert log
Webhook status: Timeout exceeded	Receiver slower than 3 seconds	Reply first, do slow work after
Alert stopped	More than 15 triggers in 3 minutes	Fewer alerts per bar
Old behaviour after an edit	Alert runs the saved snapshot	Recreate the alert

The decision rule: if the alert log time equals the bar close plus a few seconds, stop tuning TradingView and look downstream. If it is 600 seconds late on a CME symbol, fix the data first. If the Webhook status shows an error, the fix is on the receiving side, and no TradingView setting will change it.

Go deeper

Frequently asked questions

Do TradingView alerts keep working when my browser is closed?

Yes. TradingView says its alerts run on its own servers, using a saved copy of the script, inputs, symbol and timeframe. Your open chart is not the alert, so closing the tab or shutting down your computer does not stop it.

Does a higher TradingView plan make alerts fire faster?

There is no evidence that it does. TradingView publishes no alert speed figure for any plan. Plans differ in features such as alert expiry and webhook access, so check the alert dialog and the pricing page for what yours includes.

Can I send a TradingView webhook to a custom port or an IPv6 address?

No. TradingView accepts only ports 80 and 443 when a URL includes a port number, and it does not currently support IPv6 for webhooks. Put the receiver behind an endpoint on port 443 if your service listens elsewhere.

Can a TradingView webhook reach a server on my home network?

Not by a private address. TradingView's error reference lists URLs that resolve to a private or internal IP, and localhost, as errors. The receiver needs a public address that allows TradingView's four published sending IPs.

Why is the webhook option missing or disabled in my alert dialog?

TradingView allows webhook alerts only when 2-factor authentication is enabled on the account. Webhooks also depend on your plan, and TradingView's pricing page could not be read unambiguously in October 2026, so confirm in your own account.

What does a 4xx error in the Webhook status column mean?

Your receiver rejected the request. TradingView's error reference gives typical causes: a wrong endpoint, failed authentication, invalid JSON in the message, or too many requests. Fix the message or the receiver, not the alert timing.

Will enabling calc_on_every_tick make my strategy alerts fire sooner?

It lets the strategy recalculate on every realtime tick instead of once at bar close, so alerts can fire intrabar. The cost is consistency: history is still calculated once per bar, and TradingView names this setting as a common cause of mismatches between alerts and chart orders.

Do TradingView alerts fire for signals on historical bars?

No. Alerts trigger only on realtime bars, and TradingView sends no notifications for strategy orders on historical bars. Creating an alert never replays past signals, so the first alert arrives with the next qualifying live bar.