Latency Budgets From Alert Fire to Order Acknowledgement

Most desks can tell you their average alert to order time and almost none can tell you their ninety ninth percentile. This is exactly backwards. The median describes the day nothing happened. The tail describes the morning the feed backed up, three rules fired at once and the one order that mattered went in ninety seconds after the level was gone, and the tail is also where the strategy either survives or does not.

A latency budget fixes the conversation by turning an aggregate into a set of per hop commitments with percentile targets attached. It gives you somewhere to attribute a breach, a defensible answer when an allocator asks how you know your signals are actionable, and a documented threshold at which a strategy stops trading.

Name the hops before you measure anything

The chain from a condition becoming true to a venue confirming an order has more segments than the two most people describe, and each has a different owner and a different failure mode.

Data arrival, where the input the rule reads reaches the platform. Rule evaluation, where the condition is tested and found true, which is bounded by evaluation cadence rather than by processing speed: a condition on a fifteen minute construct cannot be known sooner than the construct is complete, and that is a property of the signal you chose, not a defect. Dispatch, where a message is emitted to a channel. Delivery, where the channel operator, mail server or chat provider actually hands it over, and where you have no control at all. Then either human decision, or receipt by your own system if the destination is a webhook. Then order construction, transmission, and venue acknowledgement.

Two of these are not yours. Delivery through a third party messaging provider is unmeasurable from the inside and unbounded in the tail, which is the single strongest argument for routing anything time critical to a webhook into your own infrastructure rather than to a mailbox or a chat channel. And the human hop, if you have one, is not a latency problem at all. It is a staffing and attention problem wearing latency's clothes, and it belongs in the budget with an honest number rather than a flattering one.

What the ledger will and will not tell you

The Alerts and Subscriptions page is a ledger of configured rules rather than an instrumentation surface. A row carries the rule name, its logic and conditions, a channel badge, an enable toggle, a last fired date, and controls to test fire, edit or delete, with a History tab alongside. The header tiles count total alerts, active against paused, channels in use and distinct categories. The channel line reads email, Discord, Telegram and webhook.

A last fired date is a date. It is not a timestamp you can difference against a venue acknowledgement, and nothing on this page publishes per hop timings. So the measurement is yours to build, and the test fire control on each row is the most useful thing here, because it gives you a controlled injection point: you decide when the message is emitted, which means you know one end of the interval exactly.

Instrument the rest at the receiving end. If the destination is a webhook, log receipt time at your endpoint to the millisecond with a clock you trust, carry a correlation identifier through order construction, and capture the venue acknowledgement time from the exchange or broker response rather than from your own send. For human hops, timestamp the acknowledgement and the order separately, because collapsing them hides the difference between somebody who was slow to see the message and somebody who saw it and thought about it.

Why the budget is written in percentiles

Publish three numbers per hop, not one. The p50 tells you the system is configured correctly. The p95 tells you what the desk experiences on a busy morning. The p99 tells you what happens when everything correlates, which is the only scenario where latency has ever cost anyone real money, because the moments when your alert is slow are the moments when everyone else's is firing too.

The table below is the shape rather than the content. The numbers in your version come from your own capture over a meaningful sample, and any figure in it that was not measured should be left blank rather than estimated, because an invented budget is worse than none: it will be quoted back to you in a review.

Two rules keep the budget honest. Percentiles do not add, so the p99 of the total is not the sum of the per hop p99s and is usually smaller, which means the end to end figure has to be measured end to end rather than assembled. And every target needs a sample count beside it, because a p99 computed on eighty observations is a single unlucky event with a decimal point.

Deriving the number from the signal rather than from ambition

A budget nobody derived is a budget nobody defends. Work backwards from the decay of the edge instead. Take the signal your rule watches, measure how the realised move behaves at increasing delays after the condition becomes true, and find the delay at which the remaining move no longer covers your expected cost of crossing the spread. That is your end to end ceiling, and it is a property of the strategy rather than a preference.

Do this per strategy family, because the answers differ by orders of magnitude. A rule watching a fifteen minute reversal construct on a liquid instrument tolerates a budget measured in tens of seconds. A rule watching a listing or a filing tolerates rather less and competes with participants who removed the human hop entirely. A rule watching a macro condition to trigger a rebalance can tolerate hours, and giving that one a tight budget wastes engineering on a hop that was never the constraint.

Then compare the ceiling with the measured p95. If the measured tail exceeds the ceiling, you have three options and only three: remove hops, reduce the size you commit at that latency, or stop running that strategy through that path. Widening the budget to match what you measured is not on the list, though it is the most common outcome.

The breach rule, and the button nobody automated

A budget without a consequence is a chart. Define the breach as a sustained condition rather than a single observation, since one slow message is an event and a shifted distribution is a fault. Something of the form that the rolling p95 over a stated window exceeds the ceiling, evaluated on a minimum sample, is defensible and hard to game.

Now the part that has to be said plainly, because the phrase taking a strategy offline automatically invites a dangerous assumption. Nothing in the alerting surface does this. The Autopilot page carries fleet level actions, pause all, resume all, and an emergency kill switch, and they are manual buttons. There is no latency threshold you can configure there that halts a book on your behalf, and the kill switch applies to the whole fleet rather than to the one strategy whose path degraded.

So the automation, if you want it, lives in your infrastructure. The pattern that works is a gate in your own order path: your monitor evaluates the rolling percentile, and when it breaches, your system stops acting on messages from that source and raises an incident. That is a change you own and can test. What you must not do is write a policy that says a strategy goes offline on breach and leave the execution of that policy to whoever happens to be watching, because the breach and the busy morning are the same morning, and that is precisely when nobody is watching a latency dashboard.

Finally, keep the measurement running when nothing is wrong. The tail moves for boring reasons: a provider changes routing, a chat client changes its notification behaviour, a venue adds a risk check to its acknowledgement path. None of these announce themselves, and all of them show up first in the ninety ninth percentile of a chart nobody opened.