The latency of an execution router is a measurable fact, so we treat it as one. Here is exactly what we measure, where, how — and what we deliberately leave out.
Public latency measurement in progress. We publish p50/p95 signal→broker-ACK latency per environment once the sample is statistically defensible — not before.
Read the measurement methodologyPipSync's latency figure is the interval between two events we control and timestamp ourselves: the moment a signal is fully ingested and parsed on our servers (the signal-ingest timestamp) and the moment the destination broker acknowledges the resulting order (the broker order ACK). We call this the signal→broker-ACK interval. It is the portion of the pipeline PipSync is actually responsible for — parsing, risk checks, sizing, routing and submission. Everything inside that window is our engineering; everything outside it is not, and we do not claim it.
Latency is reported per environment, because a number without a location is marketing, not evidence. Each published figure names the server region it was measured from (for example, a Frankfurt eu-central deployment) and the broker endpoint class it was measured against. Routing distance, peering and broker API responsiveness differ by region and venue, so a single global average would hide exactly the variation that matters to you. When we publish, the region is attached to every percentile.
We publish p50 (median) and p95, not a mean. An average is trivially distorted by a handful of unusually fast or slow samples and tells you almost nothing about a single order. The median (p50) is the latency half your orders beat; p95 is the latency 19 out of 20 orders beat — the near-worst case you should plan around. Tail behaviour is the whole point of an execution router, so we lead with the tail. We also publish the sample size and the as-of date of the cut, so the figure can be judged and, if you like, challenged.
We publish only when the sample is large enough to be statistically defensible — not on day one, and not from a cherry-picked window. Until then this page shows a "measuring" state and no number at all. A placeholder adjective ("fast", "low-latency", "tracked") is not evidence, and we would rather show nothing than show something we cannot defend.
Two things sit outside the signal→broker-ACK window and are not counted in our figure. First, broker-internal fill time: once the broker acknowledges the order, how long its matching engine takes to fill is their system, not ours, and varies by liquidity and instrument. Second, the signal source and your own network: how quickly Telegram, Discord or a webhook delivers the original message to us, and your connection to our dashboard, are upstream of the interval we measure. Including either would inflate or deflate our number with factors we do not control — so we exclude them, and we say so.