Missing ticks on single WebSocket connection with ~500 tokens in MODE_LTP — Candle Low not captured

aagshah

Environment

• Library: pykiteconnect (latest)
  

• Subscription: ~500 tokens (Nifty 500 universe), all in MODE_LTP
  

• Connection: Single WebSocket instance
  

Issue Description

I am subscribing to approximately 500 instrument tokens over a single WebSocket connection in MODE_LTP. I am consistently observing that ticks for certain scrips are missing — specifically, extreme intrabar price points (highs/lows) are never received via the WebSocket even though they are reflected in the official 1-minute OHLC candle.

Concrete Example — FINCABLES, 10th March 2026, 14:06 candle:

2026-03-10 14:06:02,731 - INFO - Symbol: FINCABLES | LTP: 938.00
2026-03-10 14:06:05,980 - INFO - Symbol: FINCABLES | LTP: 938.25
2026-03-10 14:06:06,730 - INFO - Symbol: FINCABLES | LTP: 938.25
2026-03-10 14:06:10,986 - INFO - Symbol: FINCABLES | LTP: 937.80
2026-03-10 14:06:13,732 - INFO - Symbol: FINCABLES | LTP: 937.85
2026-03-10 14:06:14,987 - INFO - Symbol: FINCABLES | LTP: 937.85
2026-03-10 14:06:16,234 - INFO - Symbol: FINCABLES | LTP: 937.85
2026-03-10 14:06:20,981 - INFO - Symbol: FINCABLES | LTP: 937.75
2026-03-10 14:06:21,480 - INFO - Symbol: FINCABLES | LTP: 937.75
2026-03-10 14:06:26,230 - INFO - Symbol: FINCABLES | LTP: 937.80
2026-03-10 14:06:28,229 - INFO - Symbol: FINCABLES | LTP: 937.80
2026-03-10 14:06:29,983 - INFO - Symbol: FINCABLES | LTP: 937.80
2026-03-10 14:06:32,981 - INFO - Symbol: FINCABLES | LTP: 937.80
2026-03-10 14:06:35,483 - INFO - Symbol: FINCABLES | LTP: 937.70
2026-03-10 14:06:37,230 - INFO - Symbol: FINCABLES | LTP: 937.90
2026-03-10 14:06:38,480 - INFO - Symbol: FINCABLES | LTP: 935.10
2026-03-10 14:06:39,735 - INFO - Symbol: FINCABLES | LTP: 935.10
2026-03-10 14:06:41,737 - INFO - Symbol: FINCABLES | LTP: 935.10
2026-03-10 14:06:43,482 - INFO - Symbol: FINCABLES | LTP: 934.90
2026-03-10 14:06:46,231 - INFO - Symbol: FINCABLES | LTP: 935.00
2026-03-10 14:06:46,983 - INFO - Symbol: FINCABLES | LTP: 935.10
2026-03-10 14:06:47,982 - INFO - Symbol: FINCABLES | LTP: 935.05
.
.
... more ticks ...
.
.
2026-03-10 14:06:59,735 - INFO - Symbol: FINCABLES | LTP: 935.70


These are all consecutive ticks in the 14:06 minute.

The ohlc for the 14:06 candle was as follows:
O - 938
H - 938.25
L - 931.35
C - 935.7

The lowest LTP I received was 935.10. The actual low of 931.35 — a ~3.75 point gap from the lowest tick I received — was never broadcast to my client. This is not an isolated incident; it occurs frequently across multiple scrips throughout the trading session.
Impact: I am placing SL-Limit orders based on real-time tick data. Missing extreme price points means my SL trigger logic operates on an incomplete picture of actual market prices, leading to incorrect order placement decisions.

Questions
1. Multiple WebSocket connections — will it help?
Would splitting the 500 tokens across 2–3 WebSocket connections (e.g., ~170 tokens each) result in more complete tick delivery? Or is the bottleneck on the server-side broadcast layer, meaning splitting connections wouldn't change the number of unique ticks received per instrument?
2. Is this a known/ongoing issue?
Is the missing of extreme intrabar ticks a known limitation of the WebSocket feed, or is this a bug that is actively being investigated? I'd like to understand whether this is expected behaviour (i.e., Zerodha's WebSocket sends periodic LTP snapshots rather than every individual trade tick) or an anomaly.
3. Recommended architecture for tick-sensitive strategies?
Given that SL-Limit order placement depends on accurate real-time price data, what is the recommended approach? Specifically:

• Is MODE_QUOTE or MODE_FULL more reliable for capturing intrabar extremes?
  

• Is there a way to reconcile missed ticks in near-real-time (e.g., polling the quote API as a fallback)?
  

Expected behaviour: All traded price points (or at minimum, intrabar highs/lows) are reflected in the WebSocket stream.
Observed behaviour: Extreme intrabar price points are silently skipped and never received by the client.
Any guidance from the Zerodha team or community would be greatly appreciated.

Thanks,
Aagam Shah

aagshah

Currently, I believe I am blocking the websocket thread by throwing computations on the ticks when they arrive, which might be leading to this issue. As a possible solution, I am thinking of introducing a queue to store all the ticks as soon as they arrive. All the computations will be done by dequeing it. Let me know if this sounds like a feasible approach.

nagavenij

When the WebSocket thread is blocked, some ticks may be lost and cannot be retrieved later. Splitting tokens across 2–3 WebSocket connections does not guarantee that you will receive more ticks.

Please note that the data received for the Kite chart may not exactly match the data received on your WebSocket. Although both originate from WebSocket streams, the data received across two WebSocket connections can differ. This is expected and is part of the system architecture.

aagshah

If both originate from the same WebSocket streams, why can there be a difference in the ticks received ? Would want to know why this is an expected behaviour.

Nivas

Although both the Kite chart data and Kite Connect Websocket data originate from the same underlying stream, they are delivered through two separate WebSocket connections. Because of this architectural design, slight differences in the ticks received across the two streams are expected.

It’s important to note that WebSocket connections function independently. Since the ticker broadcasts the latest market snapshot at the moment of transmission, no two streams are guaranteed to be identical. Each connection captures its own “slice” of the market data, and because the sockets are not synchronized with one another, variations in the number of ticks received can occur.

Please check out this thread for more information.

aagshah

Got it.

However, in the example stated above, the time difference between 2 consecutive ticks is ~ 3-4 secs. Isn't that too much latency, or is that the expected behaviour too ? Ideally, ticks at a gap of ~1s are what one would expect.

Tickers like HDFC Bank, Reliance and other large cap stocks have a very good tick arrival rate (2 ticks/sec) but stocks like the one in the example above have a poor tick arrival rate. What might be the reason behind the difference ?

Since kite claims to broadcast a tick as soon as a price change is observed, a tick close to 931.35 should have been
broadcasted but the closest tick was nowhere near (it was 935.05). Is this expected for low liquidity stocks ?

nagavenij

The ticks may not have been broadcast due to the thread being blocked, as mentioned earlier. Even after refactoring this implementation, there is still a possibility that not all ticks will be captured.
Because when viewing a 1-minute chart, thousands of ticks may occur during that interval. However, the charting platform usually captures only a subset of those ticks—often a few hundred.
Based on this sampled data, the Open, High, Low, and Close (OHLC) values are derived and used to plot the candle. Since each websocket may capture a slightly different subset of ticks, the recognized data points—and consequently the OHLC values—can vary slightly from one websocket to another.

Tick frequency depends on the liquidity of the scrip. For highly liquid instruments, you can generally expect to receive at least one tick per second, and often more during active trading periods, provided the WebSocket connection is not blocked.
For illiquid instruments, the tick frequency may be lower, depending on how often trades occur or quotes change at the exchange.