Diagnose TradingView alert delay

Separate five parts of the alert path

Start with the earliest point where the observation differs from your expectation. Preserve the exchange-qualified symbol, chart interval, session, script version, inputs, alert frequency, and delivery channel so that comparisons refer to the same configuration.

Check the trigger before changing the frequency

For alert() calls, alert.freq_once_per_bar_close permits a notification only when the call executes on the realtime closing update. It does not save an earlier crossover. Changing to once per bar can permit an earlier call, but a signal observed during an open bar may disappear before close.

• A default strategy calculates at bar close. Changing only alert() frequency does not make it calculate on every tick. Intrabar recalculation changes behavior and needs separate testing.
• TradingView documents that Once Per Bar Close alerts can wait for the first trade of the next bar. When trades are absent, its server closes the bar one minute after the formal close. This is a documented case, not a universal delivery estimate.
• Check whether the chart reports delayed data for the exact exchange symbol. Comparing different exchanges or feeds can create an apparent timing mismatch.
• Recreate the alert after changing script code, inputs, symbol, or timeframe: the running alert uses the snapshot saved at creation.
• For strategy order-fill alerts, compare the realtime alert event with the emulator fill. A historical Strategy Tester timestamp can use the bar opening time and is not evidence of webhook delay.

Record timestamps without overstating what they prove

Use UTC and a consistent unit, such as Unix milliseconds, in your own logs. Synchronize receiver clocks and record their uncertainty. For durations inside one service, prefer a monotonic clock. Keep a correlation key so a retry or a different event is not mistaken for the original notification.

//@version=6
indicator("Alert timestamp diagnostics", overlay = false)

int length = input.int(14, "RSI length", minval = 1)
float threshold = input.float(70.0, "Cross above")
float rsi = ta.rsi(close, length)
bool crossed = ta.crossover(rsi, threshold)

if crossed and barstate.isconfirmed
    string eventId = syminfo.tickerid + ":" + timeframe.period + ":" + str.tostring(time) + ":rsi_up_v1"
    string closeTime = na(time_close) ? "null" : str.tostring(time_close)
    string payload = '{"event_id":"' + eventId + '","bar_open_ms":' + str.tostring(time) + ',"bar_close_ms":' + closeTime + ',"eval_ms":' + str.tostring(timenow) + '}'
    alert(payload, alert.freq_once_per_bar_close)

plot(rsi, "RSI")
hline(threshold, "Threshold")

Run a controlled live diagnostic

Add the example to a chart and create an alert using Any alert() function call. Use a test receiver with no live-order action. Historical plots do not emit a history of notifications, so collect future realtime events and preserve the matching alert-log entries. This procedure has not been presented as a measured test result.

• First verify the source: record the exchange-qualified ticker, interval, session, and data-delay status. Save the alert configuration and script revision with the observations.
• For each event, store the received body and a timestamp at the first receiver boundary you control. If a proxy or gateway precedes your app, collect its arrival time too.
• Record receipt, durable acceptance, queue entry, worker start, completion, and downstream acknowledgement as distinct events. Avoid logging secrets or account credentials.
• Join the payload and receiver logs with event_id. The example key identifies one signal per symbol, interval, bar, and code suffix; add your own configuration identifier when testing multiple alert instances.
• Compare several events under the same configuration, including ordinary and busy periods. Report sample count, observation window, missing events, and clock uncertainty before reporting any latency distribution.
• Change one factor, such as the receiver processing path or script condition, then collect a new sample. If the alert log is timely but one channel arrives late, investigate that delivery path. If the event itself is late, retain the source-data and trigger evidence for TradingView support.

Handle webhooks promptly and preserve evidence

TradingView documents a three-second request-processing timeout for webhook receivers. That is a request constraint, not a promise that an alert arrives within three seconds. It also notes that webhooks can occasionally fail to reach their destination; check the Webhook status column in the alert log.

• A receiver design can validate the message, durably accept it, and respond before doing slow downstream work. Returning success before storing the event risks losing it if the process stops.
• Use correlation and duplicate handling before connecting a receiver to any external action. Record an accepted request separately from a completed action.
• Compare actual measurements before selecting a hosting region. The sources here do not establish a universally fastest region, a premium-plan latency advantage, or a fixed dispatch time.
• If code review is warranted, inspect the condition and calculation schedule first. Simplifying a script cannot fix delayed exchange data, platform delivery failures, or a slow broker service.