TradingView Webhook Delay
Official specs, common causes, and what you can fix

You set up a TradingView alert to auto-trade, and the signal shows up later than you expected — sometimes a few seconds, sometimes what feels like several minutes. Here's the short version: eight times out of ten, the delay you're feeling isn't TradingView itself being slow. It's one of three things — (1) the alert frequency you chose is doing exactly what you told it to, (2) your own receiving server is responding too slowly and getting timed out, or (3) your plan doesn't even support webhooks.

One honest thing up front: TradingView has never publicly promised a webhook delivery time, and there is no SLA. This post won't hand you a made-up "average delay is X seconds" number. Instead it lays out what the official docs actually specify, the plan restrictions, the community reports labeled as such, and — most usefully — which delays you can fix and which are structural.

Debunking the biggest myth first: "Once Per Bar Close" isn't slow, it's deliberate

TradingView's own docs define alert frequency clearly: Once per bar checks every bar and fires the moment conditions are met, no more than once per bar, without waiting for the close. Once per bar close uses the same logic but requires the bar to close before it fires. That one word — "close" — is what decides whether your signal feels instant or feels slow.

One more distinction people miss: the frequency labels above belong to the "Create Alert" dialog UI, and apply to price/technical/alertcondition() alerts. Pine's alert() function has an entirely different freq parameter with only three legal values — alert.freq_once_per_bar (default),alert.freq_once_per_bar_close, and alert.freq_all. There's no "Once Only" and no "Once per minute" equivalent at the code level, even though a lot of tutorials treat them as interchangeable.

Strategies also recalculate at bar close by default: unless calc_on_every_tick = true is enabled in your code, alert() only fires once at the close no matter what freq you set, even alert.freq_all. This is the real reason behind "my strategy is supposed to be real-time but still waits for the close."

What does TradingView actually commit to?

Searching the official Help Center, Pine Script docs, and the status page turns up nothing that quantifies webhook delay or delivery time as an SLA. What the docs do specify, precisely, are these receiving-end specs — not TradingView's internal processing time:

In other words, what's officially promised is how fast your server has to respond — not how fast TradingView itself goes from condition-met to webhook-sent. There is no public number for the latter.

Your plan might not even support webhooks

Before you go chasing latency, rule out something more basic: the free Basic plan doesn't support webhook notifications at all. On the pricing page comparison table, that's a flat "no", not "slower".

What you can fix yourself vs what you can't

Here's the same set of official specs and common gotchas organized into two buckets — things you can change, and things that are structural.

Your own server is a delay source too — here's how we handle it

The "3 seconds, no retry" rule earlier is easy to underestimate. If your receiving server does everything in one request — validate the signal, call the exchange API, wait for the fill — it's very easy to blow past 3 seconds under real trading conditions. When that happens, TradingView marks the request failed and drops it, with no retry. You may never even notice the signal was lost.

TVSBot acknowledges the webhook immediately on receipt and pushes the actual order logic to a background job, specifically to avoid tripping TradingView's 3-second timeout. Our own FAQ documents this leg — signal received to order placed — as: a target P95 under 500ms, with actual latency typically totaling 1-3 seconds. That's our own stated target and general experience, not a benchmark with a published testing methodology — we're noting it here to be transparent about what the receiving end can realistically achieve, not to dress it up as a precise number.

For a full walkthrough of wiring up the webhook and what fields your payload needs, see the TradingView Webhook Complete Tutorial. If your order sizes don't match what you expected, that's usually a separate trap covered in the qty_type semantic trap post.

Source verification: IP allowlist vs SSL certificate

The IP addresses TradingView currently publishes for webhook requests (verified as of July 2026) are:

52.89.214.238
34.212.75.30
54.218.53.128
52.32.178.7

But the docs never promise this list stays fixed forever. A more durable approach is verifying the SSL certificate TradingView attaches to each request (CN = webhook-server@tradingview.com) — TradingView provides this itself, and it's more reliable than an IP allowlist alone.

Diagnosing why your alert "feels slow"

Pre-launch checklist

• Confirm your plan supports webhooks (Essential or above) — free Basic doesn't
• Pick the right frequency: Once per bar for real-time, Once per bar close for confirmed closes
• Your server returns 200 immediately on receipt — never run the full order flow inside the 3-second window
• Verify requests are genuinely from TradingView via SSL certificate, or at minimum an IP allowlist
• Delete and recreate alerts after editing Pine code — they don't auto-update
• Check Alert Manager periodically for a red "Stopped — Expired" status