Every tracking product quotes a number. Ours is a median under 100 milliseconds. The number is easy to print and hard to interpret, so it is worth pulling apart what it measures, what it does not, and where the rest of your latency budget goes.
The clock starts at publication, not at pickup
The most common way to make a latency figure look good is to start the clock late. If you measure from the moment your own system notices a post, you are measuring your own reaction time to yourself.
We measure from the timestamp the source platform assigns the post. That timestamp is embedded in the post identifier itself, so it cannot drift with our infrastructure. When we say a median under 100 milliseconds, we mean the gap between a post existing in the world and existing on our servers.
A median is not a promise
Half of monitored posts arrive faster than the median. Half arrive slower. Anyone quoting a single number without saying which half you are looking at is quoting a best case and calling it typical.
Tail latency is where the interesting failures live. A feed that is usually instant and occasionally three seconds late is a different product from one that is reliably fast, and only one of them is safe to automate against.
Detection and delivery are different problems
Detection is what the number above describes. Delivery is what happens next, and it depends entirely on how you receive the feed:
- The WebSocket API pushes to an open connection. There is no polling interval to wait out and no queue to drain.
- A Discord bot inherits Discord's own delivery characteristics, which no provider controls.
This is why our plans differ on delivery speed rather than detection speed. The feed underneath is the same. What changes is how many hops sit between the post and your code.
Where your own budget goes
Once the event reaches you, the remaining latency is yours. Parsing, filtering, deciding, and acting all cost time, and in practice they usually cost more than the network hop that preceded them.
The useful exercise is to measure your own path end to end and find out which part is actually slow. Teams are often surprised to learn the feed was never the bottleneck.
What to ask any provider
Three questions separate a real number from a marketing one:
- Where does your clock start?
- Is that a median, a mean, or a best case?
- Does the number describe detection, delivery, or both?
If the answers are vague, the number is decorative.