Where the Second Goes: A Measured Latency Breakdown

By the TradeAon team · Published 18 August 2026 · Updated 18 August 2026 · 8 min read

Copy-trading services advertise latency in milliseconds, almost always as a single number with no explanation of what was measured between which two points. A single number is not useful, because the delay is a chain of four separate stages and only some of them are anyone's to control. This page breaks the chain apart using timings taken from our own logs, including the segment that turned out to be the largest — and the one we cannot do anything about.

Why one number tells you nothing

"Sub-100 ms copying" is a claim you will see often. It can be perfectly true and still be irrelevant, because it usually describes one hop — the time for a message to cross a network — rather than the interval a trader actually cares about, which is from the master's position existing to the follower's position existing.

Those are very different quantities. Between them sit a broker accepting an order, a terminal noticing a change, a server processing and queueing, another terminal collecting the work, and a second broker filling. Measuring one link and quoting it as the whole chain is not dishonest by intent so much as by omission, and it sets an expectation the system was never going to meet.

Measuring the chain properly also has a practical purpose beyond honesty: it tells you where optimisation is worth the effort. Before measuring, our assumption was the same as most people's — that the network was the problem and a faster server location would fix it. The measurements said otherwise, and saved us from optimising the fastest part of the system.

The four segments, measured

These are timings from real trades on a live account, instrumented with a debug flag that is off by default. Each segment was measured against a single clock at one end, which matters — segments timed across two machines mix in clock drift and stop being comparable.

Add the medians and you get roughly 708 ms, which is where the "0.7 to 1.0 second" figure comes from. The spread matters as much as the sum: a bad case in every segment at once approaches 1.7 seconds, and that combination is rare but not impossible.

Two caveats before anyone treats these as universal. They come from one broker on one account, and the fill segment in particular varies enormously between brokers and between instruments. And they were taken during normal market conditions — the interesting question for any latency figure is what it looks like during a news spike, which is exactly when it is hardest to measure and when every venue is slowest.

The broker: the biggest slice, and not ours

The single largest segment, by a wide margin, is the last one: 491 ms median between the follower's terminal sending the order and the broker confirming the fill. That is roughly 70% of the total, and it happens entirely inside infrastructure no copy service touches.

This reframes the whole optimisation question. Even a copy layer that executed in literally zero time would only take the round trip from about 0.71 s to about 0.49 s — an improvement of under a third, for infinite effort. Any claim of end-to-end copying substantially faster than that is either measuring something else, or describing a broker much quicker than this one.

It also means execution speed at your broker is worth testing before you compare bridges. If the delay genuinely matters to your strategy, the fill segment is where the difference between two setups will actually show up.

The server: a small median hiding a large tail

Our own segment — receiving a signal and getting it onto the queue — has a median of 12 ms. Quoting that alone would be the same omission this page is complaining about, because the same segment reached 384 ms at its worst. That is a thirty-fold spread, and the maximum is what a trader would actually notice.

Spikes of that shape have a familiar cause in any system like this: work that is not strictly required to accept the signal ending up in front of the step that accepts it. The principle that removes them is to feed the queue first and let the bookkeeping catch up afterwards, so a slow write delays a record rather than a trade.

The general principle applies well beyond this codebase: the median tells you how the system behaves, the maximum tells you how it fails. Latency work that only tracks averages will optimise the case nobody complains about while the tail stays exactly where it was.

Queue wait: the segment you can trade against volume

Queue wait is different from the other three, because it is not really a delay in the physical sense. A command sits in a queue until the follower's terminal next asks for work, so the wait is a function of how often it asks. The average wait is about half the polling interval: with a 250 ms interval the expected wait is roughly 125 ms, which matches the 118 ms median in the table closely enough to confirm the model.

That makes it the one segment with a direct control — and the control is not free, because every reduction in wait is paid for in requests per terminal, multiplied by every terminal connected at once. Halving the interval halves the average wait and doubles the request rate.

We have already taken that trade once, tightening the interval and cutting roughly 50 ms off the average wait. Going further has sharply diminishing returns: shaving another 50 ms from a chain whose broker segment alone is 491 ms is not a difference a trader can act on, and it raises load for every connected account simultaneously. The honest position is that this segment is tuned to the point where the next gain costs more than it is worth.

What to expect, and when latency actually matters

The practical summary is short. Expect roughly 0.7 to 1.0 second for a copied trade under normal conditions, occasionally more. If you see something dramatically slower, the likely explanations are worth checking in this order: a burst of many signals at once, a terminal that has fallen behind, or a broker being slow — not a network problem, which is where most people start looking.

Whether that is fine depends entirely on what you are running:

• Swing and position strategies — a second is irrelevant. Price will move further than that between one candle and the next.
• Intraday strategies on 5-minute charts and above — comfortable. The delay is small compared to the noise in your entry.
• Scalping in a fast market — noticeable, and the amount of slippage depends on the instrument's own volatility rather than on the delay figure.
• Latency arbitrage — not viable, and not viable with any similar architecture. That strategy needs co-location, not a bridge over the public internet.

One last thing worth internalising: what matters to most strategies is not the median delay but the variance of it. A consistent one-second delay can be reasoned about and backtested against. A delay that is usually 200 ms and occasionally two seconds is much harder to account for, which is why the maximum column above is published next to the median rather than quietly dropped from the summary.