Signal Latency

Signal latency is the elapsed time between a market event or strategy condition becoming true and the resulting signal reaching the system or person expected to act on it. In trading software, that path may include market-data ingestion, indicator calculation, rule evaluation, message serialization, network transport, routing, and final display or order submission. It matters because a signal can be logically correct yet operationally useless if the market has moved before the receiver sees it.

Latency isn't one number with one cause. A chart alert delivered after a bar closes has different timing limits from a tick-driven strategy connected to a broker through the Financial Information eXchange (FIX) protocol or a WebSocket stream. Operators need to know where delay enters the chain, how it is measured, and whether reducing it changes trading outcomes enough to justify added cost and complexity.

How Signal Latency Builds Up

A signal pipeline behaves like a relay race: each stage adds a little time, and one slow handoff can dominate the result. The main sources of delay are:

• Market-data delay: Time between an exchange event and receipt by the strategy.
• Processing delay: Time spent decoding data, updating state, calculating indicators, and evaluating rules.
• Queueing delay: Time an event waits behind other work in a message queue, worker pool, or event loop.
• Transport delay: Time used by WebSocket, HTTP, FIX, email, SMS, push notification, or webhook delivery.
• Receiver delay: Time before the destination application parses, stores, displays, or acts on the message.

A common mistake is to measure only network travel time. If a strategy evaluates once per second, the scheduler alone can add almost a full second even when the network is fast. The same issue appears in bar-based systems: a five-minute strategy may intentionally wait for a confirmed candle close, so that delay belongs to the trading method rather than the infrastructure.

Measuring Latency Without Fooling Yourself

Reliable measurement needs timestamps at several points, not one sent_at field. Record the market event time, data-receipt time, signal-generation time, dispatch time, receipt time, and action time. This separates data latency from calculation, delivery, and execution latency.

Clock handling is the trap. Two servers with unsynchronized clocks can report negative latency or hide a real delay. Network Time Protocol (NTP) is often adequate for business alerts, while Precision Time Protocol (PTP) may be used when tighter timestamp accuracy is required. Within one process, a monotonic clock is safer for measuring elapsed time because wall clocks can jump during synchronization.

Bar timestamps can also produce misleading results. Many feeds label a candle with its opening time, not its closing time. Comparing a signal created at the close against the bar's opening timestamp can make latency appear equal to the entire bar interval. Operators usually verify timestamp semantics in the feed documentation and store both event time and ingestion time.

Transport Choices and Platform Behavior

Different delivery methods have different timing characteristics. Persistent WebSocket or FIX sessions avoid repeated connection setup and support continuous message flow. REST polling is simpler, but its delay depends on the polling interval and may rise under application programming interface (API) rate limits. Webhooks can be quick, yet the sender may retry after a timeout, creating duplicates unless the receiver uses an idempotency key.

Consumer channels such as email, SMS, and mobile push are useful for human awareness, not deterministic timing. Providers may batch messages, delay them during congestion, or change delivery behavior to save mobile battery. A signal shown on a browser chart may therefore arrive earlier than a phone notification generated from the same event.

Platform rules matter too. Some charting services evaluate scripts only on bar updates, while others support intrabar or tick processing. Broker bridges may translate symbols, contract sizes, or order types before submission. Those steps add time, and their behavior varies by provider, asset class, and account configuration.

Common Failure Modes and What They Look Like

Latency problems often appear as trading errors rather than obvious infrastructure alarms. Typical symptoms include:

• Stale-signal execution: Entries arrive after price has moved beyond the strategy's intended range.
• Bursty delivery: Several signals arrive together after a WebSocket reconnect or queue backlog.
• Duplicate actions: Webhook retries trigger the same order more than once.
• Out-of-order events: A close signal is processed before the matching open signal because messages took different routes.
• Silent drift: Typical delay looks acceptable, but occasional long-tail spikes cause the most damaging outcomes.

The diagnostic clue is usually the distribution, not the average. Median latency can remain low while a small number of severe delays dominate operational risk. Track latency percentiles, maximum observed delay, queue depth, reconnect counts, retry counts, and signal age at the point of action. Rejecting or flagging old signals can prevent stale automation, but the expiry rule must reflect the strategy horizon and current market conditions rather than a universal number.

When Low Latency Matters—and When It Does Not

Lower latency matters most when the expected edge decays quickly: market making, arbitrage, news reaction, short-horizon momentum, and protective exits in fast markets. In these cases, even a correct signal may lose value between generation and execution. Co-location, direct market feeds, persistent sessions, and event-driven code may be justified.

For swing trading, portfolio rebalancing, or end-of-day signals, extreme speed may add little value. Data quality, rule correctness, risk controls, and reliable recovery can matter more than shaving small amounts of delay. There's a mild contradiction here: reducing latency can improve responsiveness, yet a rushed design may become less dependable if it removes validation, retry safety, or state checks.

The practical question isn't just, “How fast is the signal?” It is, “How much does delay change the decision or fill?” Compare results across signal-age groups, slippage, missed-trade rate, rejection rate, and cancellation rate. That connects infrastructure timing to actual strategy behavior.

Reducing and Operating Signal Latency

Start with measurement, then fix the largest stage. Rewriting indicator code won't help if alerts sit in a mobile push queue, and a faster network won't solve a worker blocked by database writes.

• Keep market-data and signal-processing paths asynchronous so slow storage doesn't block live events.
• Reuse persistent connections and avoid repeated authentication where the platform permits it.
• Bound queues, expose queue depth, and define what happens when consumers fall behind.
• Attach a unique signal ID, creation timestamp, strategy version, symbol, and expiry rule to every message.
• Use idempotent receivers so retries don't create duplicate orders.
• Separate signal latency, broker submission latency, and fill latency in logs.
• Test reconnect behavior with delayed, duplicated, and out-of-order messages.

Production maintenance matters because latency can worsen without a code change. Feed providers reroute traffic, broker gateways throttle clients, certificates expire, Domain Name System (DNS) resolution slows, and message stores grow. Monitoring should therefore cover timing by stage, not merely service uptime. A system can be “up” and still be too late.