TradingView Webhook Delay: 34,174 Alerts on Real Latency
From candle close to the moment an alert webhook reaches our server, the median wait is 4.0 seconds. Not a spike, not a bad day: that is the normal case across 34,174 alerts logged over 24 straight days. Under US market load it climbs 27%, and the tail is heavy. This post is the full breakdown behind the number, measured by us, with the method and the caveats laid open.
TL;DR
- Median TradingView webhook delay is 4.0 seconds from 1-minute candle close to server receipt (n = 34,174, 24 days).
- Almost one in three alerts take longer than 5 seconds, 9% take longer than 8, and the worst hit 40.5s.
- The delay lives on TradingView's side (alert evaluation plus delivery). Our clock stops when the webhook lands, so everything after that sits outside this dataset.
- Latency tracks market activity: the US session (13:00-19:59 UTC) runs 27% slower at the median than off-peak, and weekdays run 31% slower than weekends.
- Reliable from the 5-minute chart up. One minute is marginal, 30 seconds is risky, 15 seconds is unusable, and HFT is out of reach by six orders of magnitude.
Key Takeaways
How we measured TradingView webhook latency
We ran a Pine script on a 1-minute Bybit BTCUSDT chart that fires one TradingView webhook per bar close, carrying the {{timenow}} placeholder (TradingView's own alert-generation timestamp). Our server logs the receipt time. From July 27 to August 20, 2026 that produced 34,174 measurements, one per minute.
The payload used a warm-up token, so the backend logged it and answered OK without touching an exchange. No order, no queue, no side effects. Twenty-four days at one alert per minute allow 34,560 measurements, and we captured 34,174 of them, a rate of 98.9%. We didn't establish what happened to the 386 missing points, so we report the gap without a cause.
Every alert splits into three parts, so we can see where the time actually goes:
- Engine: bar close to alert generation. This is TradingView evaluating the alert condition.
- Delivery: generation to receipt. This is TradingView's dispatch plus the network hop.
- Total: bar close to receipt. The per-alert sum, and the number that matters to you.
What the numbers can and can't tell you
Engine and delivery add up to total on every single alert. They don't add up percentile by percentile, because the median of a sum isn't the sum of the medians, so don't expect the p50 column to reconcile. {{timenow}} is truncated to whole seconds, so the split is biased and not merely noisy: the engine reads up to 1s too low and delivery up to 1s too high, about 0.5s each on average. Total never touches that timestamp, so it stays unaffected and exact.
The absolute figures include a fixed network path from TradingView to our data center in Europe, so the value lives in the shape and spread of the distribution, not in the raw network hop. Our own server runs NTP (ntp.org); we assume TradingView's does too, which we can't verify from outside. A clock offset would shift the engine/delivery split without changing the total. One probe, one account, one symbol: treat this as a deep sample of one configuration, not a survey of many.
How fast are TradingView webhooks, really?
Across 34,174 alerts the median total latency was 4.03 seconds, with a right-skewed mean of 4.71s (our study, 2026). The spread is what stings: the 90th percentile sits at 7.62s and the 99th at 16.1s. A single alert took 40.5 seconds from candle close to arrival.
Here is the full percentile table, in seconds:
| Component | p50 | p75 | p90 | p95 | p99 | p99.9 | max |
|---|---|---|---|---|---|---|---|
| Engine | 1.00 | 3.00 | 4.00 | 6.00 | 9.00 | 14.0 | 22.0 |
| Delivery | 1.63 | 2.94 | 4.74 | 6.84 | 13.7 | 23.7 | 39.5 |
| Total | 4.03 | 5.41 | 7.62 | 9.88 | 16.1 | 25.4 | 40.5 |
The engine and delivery rows carry the second-truncation bias described above, so don't read them against each other below p99. Only from p99 up is the gap wide enough to separate the two components. The total row is exact at every percentile.
Those percentiles hide the shape. Binned into half-second classes, the distribution isn't one smooth hump but a comb: peaks at 2.0-2.5s (14.2% of alerts), 3.0-3.5s (17.3%) and 4.0-4.5s (12.7%), with visible dips between them. Half the mass sits under 4 seconds, 91.0% under 8, and 95.1% under 10.
What shapes the upper two peaks is the market mix inside one dataset. The quiet hours and the busy hours sit side by side here, and the busy ones push their own hump to the right of the quiet one. Cut the data by time and those two humps separate. The 2.0-2.5s peak sits well below even the off-peak median of 3.59s, and we can't account for it from this dataset. For the payload that rides inside each of these alerts, our webhook format reference breaks the JSON down field by field.
Why is my TradingView alert delayed?
If your alert feels late, the delay is almost entirely upstream of your execution service. Delivery, not evaluation, is the bottleneck, and the tail is where you see it: delivery's p99 is 13.7s against the engine's 9.0s, and its worst case is 39.5s against 22.0s (our study, 2026). The two medians sit within the second-resolution bias described above, so they can't separate the components. The tail is far too wide for that bias to explain.
The engine stays remarkably steady. Whether the market is dead or roaring, evaluating your condition costs about the same. Delivery is the variable part.
It is TradingView's dispatch pipeline, and its mean (2.57s) sits well above its median (1.63s), which is the signature of a long tail dragging the average up. So when people ask whether a tool is "slow," the honest answer is that the seconds are spent on TradingView's side, before the webhook reaches anyone, and the dispatch queue is what makes that wait unpredictable.
Across the whole dataset, delivery swings far more widely than the engine. If you want a faster fill, the lever is not the receiving service, it is how much slack TradingView's dispatch has at that moment.
One footnote that trips people up: TradingView waits only about three seconds for your endpoint to acknowledge the POST, then logs a delivery failure even though the alert usually arrived and executed. Our guide to debugging a failed alert documents that timeout and shows how to tell the false alarm from a real miss.
Does TradingView webhook latency get worse under load?
Yes, and predictably so. During the US session (hourly buckets 13 through 19 UTC, so 13:00 to 19:59, or 9am to 4pm New York) the median total rises to 4.55s, a 27% jump over the 3.59s off-peak median, and the p99 climbs 28% (our study, 2026). The engine barely moves. The extra time is all delivery, which nearly doubles at the median.
The session cut is clean:
| Window | n | p50 | p90 | p99 | Delivery p50 |
|---|---|---|---|---|---|
| Off-peak | 24,392 | 3.59s | 7.29s | 14.8s | 1.47s |
| US session (13:00-19:59 UTC) | 9,782 | 4.55s | 8.44s | 18.9s | 2.80s |
A second, independent cut says the same thing. Weekdays run about 31% slower than weekends at the median (4.23s vs 3.24s), and every working day looks nearly identical while Saturday and Sunday dip together. Latency follows the market, full stop.
Already know your strategy tolerates four seconds?
TradingView Hub turns your webhook into a live exchange order across every major venue, with the same JSON schema everywhere.
Start Free TrialRead the webhook docsCan you scalp with TradingView webhooks?
Not at the tick level. With a 4.0s median and a 95th percentile near 9.9s, sub-second scalping over TradingView webhooks is physically impossible, and the tail makes the timing unpredictable under exactly the conditions scalpers care about (our study, 2026). Nearly one alert in three needs more than 5 seconds, 9% need more than 8, and 4.9% cross 10.
So what actually works? Strategies with room to breathe. Swing setups, higher timeframes, and levels that stay valid for minutes or hours absorb a few seconds of drift without changing the outcome. What breaks is anything betting on a precise second: tight breakout scalps, tick-by-tick entries, and stops placed inside a candle's own range.
If your edge dies in four seconds, a candle-close webhook was never the right tool. If it survives four seconds, this latency is a non-issue, and you can wire the same alert straight into an exchange like Bybit or KuCoin. Our step-by-step Bybit walkthrough covers the key permissions, the TradingView automation guide covers the full end-to-end setup, and the quickstart gets a first alert live in minutes.
Which timeframes are reliable for TradingView webhook automation?
From the 5-minute chart up. At the 90th percentile of 7.6s, a signal lands about 2.5% into the next 5-minute bar, but 13% into a 1-minute bar and halfway through a 15-second one (our study, 2026). At the 4.0s median those shares roughly halve. The higher the timeframe, the smaller the drift.
The table shows the delay as a share of a single bar. Median for the typical case, plus the 90th and 99th percentile for the bad ones:
| Timeframe | Median | p90 | p99 | Verdict |
|---|---|---|---|---|
| 15 seconds | 27% | 51% | 107% | Unusable |
| 30 seconds | 13% | 25% | 54% | Risky |
| 1 minute | 6.7% | 13% | 27% | Marginal |
| 5 minutes | 1.3% | 2.5% | 5.4% | Reliable |
| 15 minutes | 0.4% | 0.9% | 1.8% | Reliable |
| 1 hour | 0.1% | 0.2% | 0.5% | Very reliable |
A practical rule: if the 90th percentile delay stays under about 5% of your bar, the drift is noise. That puts the safe floor at the 5-minute chart. One minute is a coin toss under load, and on a 15-second bar the alert can arrive after the next candle has already closed (p99 above 100%).
What about HFT?
It is not on the table. High-frequency trading works in microseconds to milliseconds. Our median is 4 seconds, four million microseconds, so it misses the microsecond end of that range by six orders of magnitude and the millisecond end by three. TradingView webhooks are an automation tool for discretionary and systematic strategies on minute-and-up timeframes, not a low-latency execution path. No webhook relay or faster receiving server changes that, because the delay is created inside TradingView before the webhook is ever sent.
Frequently asked questions
How fast are TradingView webhooks?
Median total latency is 4.0 seconds from 1-minute candle close to server receipt, based on our own study of 34,174 alerts over 24 days (2026). The 90th percentile is 7.6s and the 99th is 16.1s, so plan for seconds, not milliseconds.
Why is my TradingView alert delayed?
The delay is on TradingView's side, split between evaluating the alert (the engine) and delivering it (dispatch plus network). Delivery is the variable part and dominates the tail, reaching a p99 of 13.7s against the engine's 9.0s in our data. Our stopwatch stops when the webhook lands, so whatever your execution service adds after that is not part of these numbers.
Does TradingView webhook latency get worse under load?
Yes. During the US session (13:00-19:59 UTC) the median rose 27% versus off-peak, and weekdays ran 31% slower than weekends in our study. The engine stayed flat, so the entire increase came from TradingView's delivery pipeline.
Can you scalp or run HFT with TradingView webhooks?
Neither at sub-second speed. With a 4.0s median and a heavy tail, roughly one alert in three takes over 5 seconds, so tick-level scalping and second-precise entries are out. High-frequency trading is further out still: it runs in microseconds to milliseconds, six and three orders of magnitude below our median (our study, 2026). The delay is created inside TradingView before the webhook is sent, so no relay or faster server closes that gap. Swing trading and higher timeframes handle the wait comfortably.
Do I need a paid TradingView plan to send webhooks?
Yes. As of August 2026, TradingView's free plan includes 3 active price alerts and 0 technical alerts, with no webhook notifications. Price alerts can still reach TV-Hub through email signals, so simple price-level automation works on the free plan. Indicator or strategy automation needs a paid plan: technical alerts and webhooks start with Essential.
Is the delay the execution service or TradingView?
TradingView. Our measurement runs from candle close to the moment the webhook lands on our server, and that whole window is TradingView's evaluation plus delivery. Anything the receiving service does after that sits outside the measured window, so this dataset can't speak to it. See TradingView's own about webhooks documentation (retrieved August 2026) for how alerts are dispatched.
Which timeframe is reliable for TradingView alerts?
The 5-minute chart and higher. At a 7.6s 90th-percentile delay, a signal lands about 2.5% into a 5-minute bar but 13% into a 1-minute bar. Keep the delay under roughly 5% of your bar and the drift is noise, which rules out sub-minute timeframes.
Four seconds is the honest number for a candle-close TradingView webhook, and it is stable enough to build around once you stop expecting milliseconds. Match your strategy's tolerance to the distribution above, lean on native exchange stops rather than second-perfect entries, and the latency stops being a mystery. If you want to put this to work, the webhook setup docs are the place to start.