Latency conversations on a signal desk usually start in the wrong place, which is the network, and end in the wrong place, which is a vendor SLA. The useful version starts with a different question: at the moment your order reaches the venue, how old is the information that justified it, and which stage of the path contributed most of that age.
Write that decomposition down once for the Market Reversal Engine and the answer will surprise nobody on the desk who has thought about it and almost everybody who has not. The dominant term is not a transport stage. It is the timeframe.
The path, stated as intervals rather than adjectives
There are six stages between a market event and a live order, and each is an interval you can in principle put a number on.
- Event to bar close. The price behaviour that constitutes the reversal happens somewhere inside a bar. The engine cannot score it until the bar completes.
- Bar close to score. Computation. MRE scoring updates on every supported timeframe close, so this stage begins deterministically and its length is a function of the vendor's pipeline.
- Score to publication. The signal appears in the live feed.
- Publication to fan-out. Email, Discord and Telegram alerts leave the vendor and traverse third-party infrastructure that neither of you controls.
- Fan-out to decision. A human or a rule engine consumes the alert and decides.
- Decision to ticket, and ticket to venue.
Most desks instrument stages five and six because those sit inside their own systems, argue about stage four because it is the one that visibly fails, and never quantify stage one at all. Stage one is where the money is.
Read the two columns in the capture together. Precision in the timestamp is not the same thing as freshness in the information, and a feed that stamps to the second invites a desk to reason as though the signal were a tick event. It is not.
The one stage the vendor quantifies
Be precise about what is published and what is not. The stated behaviour is that scoring updates on every supported timeframe close, and that new reversal signals are surfaced in the live feed within seconds of computation, then delivered by email, Discord and Telegram to subscribers.
That sentence gives you an order of magnitude for stage three and nothing else. It does not bound stage two, it does not bound stage four, and it makes no claim about the interval between an alert leaving the vendor and arriving on a phone. There is no per-stage latency table to cite here, and anyone building a budget out of assumed numbers for the unbounded stages is building a document that will be wrong in a direction they cannot predict.
So the honest budget has two kinds of line item: measured values for the stages you can instrument, and explicit unknowns with a monitoring plan for the ones you cannot. An unknown that is labelled as an unknown is a manageable risk. An unknown that has been quietly filled in with a plausible number is not.
Quantisation dominates, and it is not a defect
Here is the arithmetic that reorders the priority list. On a 15m timeframe, the evidence for a signal accumulates over a fifteen minute window and becomes scoreable only at the close of that window. The expected age of the information at the moment of scoring is therefore on the order of half the bar, and the maximum is the whole bar. That is seven and a half minutes of expected age before a single packet has moved.
Now add what the Read column tells you the engine is waiting for. A confirmed 5-minute break-down is itself a completed interval on a shorter timeframe, and confirmation of any kind is time spent by construction. This is the design working as intended. A reversal engine that fired on unconfirmed intrabar behaviour would produce a different and much noisier product.
Against that, stages two through six measured in seconds are a rounding error. If your fan-out is three seconds and you improve it to one, you have removed two seconds from a total whose leading term is measured in minutes. The improvement is real and it is worth roughly nothing, and a desk that spends an engineering quarter on it has misread its own budget.
The corollary is more useful than the complaint. If you want materially fresher signals, the lever is the timeframe, not the transport. A shorter timeframe cuts the dominant term directly and costs you signal quality, which is a trade you can evaluate. No amount of infrastructure work touches it.
Measuring the stages you own
Instrument the boundaries rather than the middles. At every hop your systems touch, record a receipt timestamp from a synchronised clock, and store it alongside the vendor's own stamp from the Time column, verbatim.
Three details separate a measurement that survives scrutiny from one that does not.
Pin the vendor clock first. The Time column does not display a timezone next to it, and every latency number you compute is a difference against that stamp. Establish what clock it runs on, document how you established it, and treat any measurement taken before that as provisional.
Report percentiles, never means. Delivery paths through third-party messaging infrastructure are heavy-tailed by nature. The mean will be fine and the ninety-ninth percentile is the one that produces the incident, and on a scalp-class signal the tail is not a slow fill, it is a signal that arrives after its own invalidation.
Sample at the hours signals actually fire. The capture stamps sit at 05:30, 08:09, 21:11, 22:06, 22:18 and 22:21. A latency study run during your own working afternoon measures a load profile that has little to do with when crypto signals appear, and the channels themselves behave differently under different regional load.
Turning the numbers into an enforceable policy
A budget nobody enforces is a spreadsheet. Two mechanisms turn it into an operating control.
The first is a staleness gate expressed in fractions of a bar rather than in seconds. If a 15m signal reaches your order logic more than some fixed fraction of a bar after its stamp, it is stale by definition and should be rejected rather than sized down, because the entry level it was built around has moved. Fractions of a bar generalise across timeframes. Seconds do not, and a fixed second-count gate will be simultaneously too tight on a daily signal and too loose on a fast one.
The second is a divergence alarm between channels. You have three delivery paths plus the dashboard, which means you have a free consistency check. When the same signal arrives on Telegram and by email with a wide spread between receipt times, the spread is the measurement, and a sustained widening is an early warning about a path you depend on. Alarm on the spread rather than on the absolute, because the absolute is contaminated by the vendor stage you cannot see.
Then state the whole thing in one line in the strategy document. Expected information age at ticket, with its dominant term named, plus the gate that rejects signals exceeding it. That sentence is what somebody should be able to read in a review when they ask why a signal-driven order went in ninety seconds after its stamp, and it answers the question better than any amount of infrastructure diagramming.