Search for futures automation and you will hit the same sentence on page after page: a TradingView alert reaches your broker in "one to three seconds." Nobody says how that was measured, on what setup, over how many alerts, or at what time of day. The figure has no sample behind it, and it is not Quantzee's figure either. This article treats it as what it is, an unsourced number in circulation, and replaces it with something you can run on your own account: a way to time each stage of the chain and a way to price the gap between the fill you were promised and the fill you got.
Here is the short version. Seconds of network delay are the smaller problem. The bigger one is that most automated futures setups act on a price that has already gone by the time the order exists. If you automate futures, you need two measurements, not one, and neither is a round-trip time.
The futures automation chain, stage by stage
An alert-driven automated futures setup has more moving parts than the phrase "alert to broker" suggests. Draw it out and you get six stages:
- Condition evaluation. Your indicator or strategy script decides a condition is true. On most setups that decision is made when a bar closes.
- Alert fires. The charting platform notices the condition and creates the alert.
- Webhook posts. The platform sends an HTTP request carrying your alert message to a URL you supplied.
- Bridge translates. A service you run or rent reads the message, maps it to an order (symbol, side, size, bracket) and sends it on.
- Broker API accepts. The broker or clearing connection validates the order and acknowledges it.
- Exchange fills. The order meets the book and trades at whatever price is there at that moment.
Only stages three to five are network and queueing time you can reasonably call latency. Stage one is a rule about when you look at the market. Stage six is the market itself. A single "round trip" figure folds all six into one number and hides which stage is doing the damage.
If you are still wiring up the front half of this chain, our TradingView alerts to webhook setup guide covers the alert and webhook stages in detail. This piece starts where that one stops and asks what the whole chain costs you.
Why bar close, not latency, is the dominant cost
Take a strategy that enters when a five-minute bar closes above a moving average. The condition cannot be known until that bar closes. At 10:05:00 the bar closes, the script evaluates, and the alert fires. By then the close price that triggered the signal is history. The next trade in the live book prints at a different price, and you are chasing it.
The strategy tester has no such problem. It reads a finished bar and books a fill from bar data. Depending on how the script is set up, that fill is either the close of the signal bar (when the script processes orders on close) or the open of the next bar (the default behaviour). Check which one your script uses, because it decides what you compare against later. Either way, the tester picks a price from historical bars with no queue, no spread to cross and no one else trading ahead of you.
Live, the same signal goes through all six stages and fills wherever the market is when stage six happens. The signed difference between the tester's price and your live fill is the real tax on a hosted automation. Part of it comes from network time, part from bar-close timing, part from spread and part from depth at the price. A single latency number can't separate them, and nobody on page one tries to.
It also explains why the same chain can look fine in one session and poor in another. A slow, rotating tape at 11:30 lets a two-second delay cost you nothing. The first minutes after a data release can move several ticks in a second. Same chain, same delay, very different bill.
A timing protocol you can run on your own account
The goal is a distribution, not a quote. Run the chain on live alerts (or on the smallest size your broker allows) and write down a timestamp at every stage you can reach. One timestamp per stage, same clock, logged for every alert.
What to log
At stage two, put the platform's own clock into the alert message. TradingView's alert message placeholders include the bar time and the time the alert fired, and at the time of writing the documentation lists {{time}} for the bar and {{timenow}} for the moment of firing. Confirm the current names against the platform's own documentation before you rely on them, since placeholders get added and changed.
At stage three, your bridge records the moment the request arrives. At stage four, it records the moment it hands the order to the broker. At stage five, it records the broker's acknowledgement time. Stage six comes from the fill report: the broker's execution timestamp and price.
Two practical notes. First, every machine in the chain should be synchronised to the same time source, or the differences between stages are noise. Second, documentation for webhook delivery states that the receiving endpoint has a short window to answer before the platform gives up on the request, so a bridge that answers slowly can lose alerts entirely. That's a failure mode a single average hides, and a log will show it.
How to read it
Collect at least a few dozen alerts before you look at anything, and more if your signal is rare enough to make that practical. Then compute each stage gap and look at the median and the 90th or 95th percentile. The median tells you the normal day. The tail tells you the day that hurts. An average sits between the two and describes neither.
Split the sample by time of day and by market condition. Alerts clustered around scheduled releases belong in their own bucket. If your stage-three-to-five gaps are small and steady while your fills still drift away from the signal price, the delay isn't the problem, and you can stop tuning the network.
Nothing here is a Quantzee dataset. We hold no measured latency sample for this chain and we aren't publishing one. The numbers in this article's worked examples are arithmetic you can reproduce, not observations.
The fill comparison: live fill against the strategy tester fill
Timing tells you how long each stage took. The fill comparison tells you what that time, plus everything else, cost in price. This is the measurement almost nobody runs.
For each live signal, find the tester's trade for the same signal on the same bar. Pair them. Record the tester's fill price, your live fill price, and the signed difference in ticks, counted so that a worse fill for you is positive. Put every pair in one table: signal bar, side, tester price, live price, difference in ticks.
Then read the table the way you read any distribution:
- The median difference is your usual cost per entry.
- The tail (worst 10% of pairs) is what a bad session looks like.
- The sign matters. If differences are mostly positive, the chain is consistently costing you. If they scatter around zero, you have noise rather than a tax.
- Do the entry and the exit separately. Stops and market exits behave differently from limit entries.
Don't average everything into one number. An average of +0.5 ticks can hide a median of 0 and a handful of +6 outliers, and those two situations call for different decisions.
For the cost side of this, see how we define slippage in the glossary. The comparison above is slippage measured against the tester rather than against the signal price, which is the version that matters for judging whether a backtest can be trusted.
Why the one-to-three-second figure doesn't transfer
Take the quoted range at face value for a moment and ask what it would have to be true of. Alert delivery varies by platform load and by how many alerts you have running. Bridge queueing depends on the bridge's own architecture and what else it is handling. Broker acknowledgement depends on the connection and on the order type. Liquidity depends on the contract and the hour. A figure that holds for one combination has no claim on another.
Several of the pages that repeat the range come from services that sell a bridge or a copier, which is a reasonable place to want the number to look small. That isn't an accusation, only a reason to treat the figure as marketing-adjacent until someone shows a sample. A fair statement from one of those pages is that end-to-end time is commonly under a few seconds while nothing in the chain guarantees it. That statement is probably true and it doesn't help you, because it says nothing about what those seconds cost in price.
If you want a sourced number, the only one that exists is the one you measure.
Contract-level arithmetic: turning ticks into dollars
A tick difference only becomes useful once it's priced. According to CME Group's contract specifications, the common index futures have the following minimum price increments and values:
- Micro E-mini S&P 500 (MES): a 0.25 index-point tick is worth $1.25, on a $5 per point multiplier.
- E-mini S&P 500 (ES): a 0.25 tick is worth $12.50, on a $50 per point multiplier.
- Micro E-mini Nasdaq-100 (MNQ): a 0.25 tick is worth $0.50, on a $2 per point multiplier.
- E-mini Nasdaq-100 (NQ): a 0.25 tick is worth $5.00, on a $20 per point multiplier.
Check these against the exchange's own contract specification page before you build a spreadsheet on them, since exchanges can revise specifications.
Now the worked arithmetic, using made-up inputs so you can swap in your own. Say your pairing table gives a median entry difference of 2 ticks on MES. That is 2 x $1.25 = $2.50 per contract on the entry. If the exit costs the same, a round trip costs $5.00 per contract before commissions and fees. Trade 3 contracts and it's $15.00 per round trip. Fifteen round trips a week and you're down $225 a week to the chain alone, on a number that never shows up in a backtest.
The same 2 ticks on ES is 2 x $12.50 = $25.00 per contract per side, so $50.00 round trip. The tick count is identical, but the dollar cost is ten times higher, because the contract is ten times larger. That's why a chain that is tolerable on micros can be a different problem on full-size contracts.
Put that next to the strategy's edge per trade. If your backtest says the average trade makes $4.00 per micro contract and your chain costs $5.00 per round trip, the strategy has no room left. This is the single most useful comparison in the whole exercise, and it needs only two inputs: the strategy's average trade and your measured round-trip cost.
Partial fills and brackets
Everything above assumes one order, one price. Real entries on active contracts often fill in pieces. A 4-lot market order can print 2 contracts at one price and 2 at the next tick. Your average entry is then between the two, and a stop attached as a bracket is sized and placed against something the tester never modelled.
The tester assumes the whole position gets the whole price. If the live bracket is placed relative to the signal price while the average fill is 1 tick worse, your effective stop distance shrinks by that tick, and your risk per trade changes with it. On a tight stop of 8 ticks, a 1 tick fill difference is 12.5% of the stop distance. That's a real change in the trade you're actually taking.
Log it. For each live entry, record the number of fills, the price of each, and where the bracket orders were placed. If the bridge sends the stop only after the entry is acknowledged, record that gap too: for those milliseconds or seconds the position is open with no protective order resting at the exchange. That depends on how the bridge was built, which is another reason to read its documentation rather than assume.
Rule out repainting before you measure anything
None of the above means anything if the signal itself isn't stable. An alert built on a condition that repaints can fire on a bar and then see that condition disappear when the bar completes. The order then goes out against a signal that no longer exists on the chart. Your pairing table will show a pile of mismatches, and you will blame the chain when the indicator is the culprit.
Before you collect a single timestamp, confirm that the condition holds after the bar closes. Our walkthrough on how to test a TradingView indicator for repainting lays out the replay method, and the roundup of non-repainting TradingView indicators is a reasonable place to check what a clean signal looks like. Only after that does a live-versus-tester comparison tell you anything about the chain.
It also helps to know how you'll replay a signal against history. Our guide to backtesting a TradingView indicator covers how the tester produces the fills you'll be comparing against, which you need to understand to read the comparison correctly. And if some of your alerts go to a phone rather than a bridge, the mobile alert workflow has a different delay profile: a push notification you act on by hand adds a human stage that no bridge log will capture.
What to do with the result
This is analysis, not advice, and what to trade is your decision. What the measurement gives you is an input. Compare three numbers:
- The median and tail of your live-versus-tester difference, in ticks and dollars.
- The edge per trade the strategy shows in the tester, in the same units.
- How often the signal fires.
A strategy with a large edge per trade and few signals can absorb a clumsy chain. A strategy that fires many times a day on a small edge per trade is the most exposed, because the chain's cost is charged on every signal while the edge is thin. If the edge per trade is smaller than the measured round-trip cost, there's nothing for the automation to work with, and no amount of faster hosting changes that arithmetic unless it moves the tick difference.
Some people will find the result uncomfortable. That is what a measurement is for. A backtest tells you what a rule would have done on historical bars with idealised fills. The pairing table tells you how far your own plumbing sits from that ideal. Both belong in the same decision.
Regulation and firm rules are a separate question and they change. If you use a funded or evaluation account, read the firm's current automation policy yourself and date what you read. For background on how the industry is overseen, the Commodity Futures Trading Commission and the National Futures Association publish investor material, and neither of them will tell you what your fills cost. Only your logs will.
Method notes and limits
The methodology in this article is a protocol, and the dollar figures are worked examples built from exchange contract specifications. None of the figures is a result from a Quantzee test. We haven't published a latency or slippage dataset for any broker, bridge or firm, and we don't rank any of them. The one-to-three-second claim appears in this article only so that it can be named as unsourced.
The page's sources are the exchange's contract specifications, the platform documentation for alert placeholders and webhook behaviour, and three public guides on prop-firm automation, which we read for what they cover and where they stop. Rules at any firm can change, so none of their policies is restated here as current.
