Ticks delayed by > 1 second consistently

[bkt]

Ticks through WebSocket are delayed by more than 1 second.

At first, I thought the issue was in my code, as the 5-minute OHLC consistently showed the Close price using the second-last tick of the 59th second (Normally I receive two ticks every second for Nifty).

After I added an insert timestamp, I noticed that the last tick of the 59th second almost always arrived at the start of the next 5-minute interval. This was evident because the Close price consistently reflected the second-last tick, not the last tick. This resulted in incorrect indicator values in my system—very dangerous for a system that depends on indicators.

To confirm that the insert timestamp delay was not due to tick processing time, I logged the current timestamp immediately after receiving the ticks and before processing them. I observed the same delay. The DB insert took only 10–50 milliseconds, which is quite negligible.

Below is the tick data and the detailed analysis.

The implication of this delay is that I have to intentionally add a 750 to 1000 milliseconds delay before the system can construct the bar OHLC, evaluate indicators, and place the first order.

Losing more than a second is significant.

I don’t know how others are coping with this. Are you also facing a similar issue?

@Zerodha, is this kind of delay in ticks expected.

Full analysis and data:

Full table is shown below (89 buckets, 08:30 → 15:55). Each row shows the tick with the latest timestamp in its 5-min window, with both the tick timestamp (from Kite WS) and the insert timestamp (server created_at).

Delay observations:
│ Metric │ All 177,017 ticks │ Last-of-bucket sample │
│ Min delay │ 0.41 sec │ 0.93 sec │
│ Avg delay │ 0.92 sec │ ~1.25 sec │
│ Max delay │ 2.98 sec │ 1.45 sec │

Patterns:

• Last-tick-of-bucket delays cluster in two bands: ~1.17s and ~1.42s — likely two different instruments with slightly different propagation/insert timing.

• Tick timestamps are second-granular (:59 consistently, since Kite stamps at second boundary), while inserts have millisecond precision.

• No bucket exceeds 1.45s at end-of-window; worst-case across the full table is 2.98s (a transient blip).

  ⎿ bucket_5min instrument tick_ts insert_ts delay_sec

  ---

  2026-04-17 08:30 260105 2026-04-17 08:34:59 2026-04-17 08:35:00.157 1.16
  2026-04-17 08:35 260105 2026-04-17 08:39:59 2026-04-17 08:40:00.166 1.17
  2026-04-17 08:40 257801 2026-04-17 08:44:59 2026-04-17 08:45:00.419 1.42
  2026-04-17 08:45 257801 2026-04-17 08:49:59 2026-04-17 08:50:00.418 1.42
  2026-04-17 08:50 256265 2026-04-17 08:54:59 2026-04-17 08:55:00.169 1.17
  2026-04-17 08:55 256265 2026-04-17 08:59:59 2026-04-17 09:00:00.177 1.18
  2026-04-17 09:00 256265 2026-04-17 09:04:59 2026-04-17 09:05:00.180 1.18
  2026-04-17 09:05 257801 2026-04-17 09:09:59 2026-04-17 09:10:00.193 1.19
  2026-04-17 09:10 260105 2026-04-17 09:14:59 2026-04-17 09:15:00.166 1.17
  2026-04-17 09:15 260105 2026-04-17 09:19:59 2026-04-17 09:20:00.159 1.16
  2026-04-17 09:20 256265 2026-04-17 09:24:59 2026-04-17 09:25:00.153 1.15
  2026-04-17 09:25 260105 2026-04-17 09:29:59 2026-04-17 09:30:00.151 1.15
  2026-04-17 09:30 256265 2026-04-17 09:34:59 2026-04-17 09:35:00.144 1.14
  2026-04-17 09:35 257801 2026-04-17 09:39:59 2026-04-17 09:40:00.140 1.14
  2026-04-17 09:40 260105 2026-04-17 09:44:59 2026-04-17 09:45:00.386 1.39
  2026-04-17 09:45 260105 2026-04-17 09:49:59 2026-04-17 09:50:00.391 1.39
  2026-04-17 09:50 260105 2026-04-17 09:54:59 2026-04-17 09:55:00.394 1.39
  2026-04-17 09:55 260105 2026-04-17 09:59:59 2026-04-17 10:00:00.393 1.39
  2026-04-17 10:00 260105 2026-04-17 10:04:59 2026-04-17 10:05:00.395 1.4
  2026-04-17 10:05 260105 2026-04-17 10:09:59 2026-04-17 10:10:00.395 1.4
  2026-04-17 10:10 260105 2026-04-17 10:14:59 2026-04-17 10:15:00.395 1.39
  2026-04-17 10:15 257801 2026-04-17 10:19:59 2026-04-17 10:20:00.399 1.4
  2026-04-17 10:20 257801 2026-04-17 10:24:59 2026-04-17 10:25:00.398 1.4
  2026-04-17 10:25 260105 2026-04-17 10:29:59 2026-04-17 10:30:00.404 1.4
  2026-04-17 10:30 257801 2026-04-17 10:34:59 2026-04-17 10:35:00.411 1.41
  2026-04-17 10:35 256265 2026-04-17 10:39:59 2026-04-17 10:40:00.165 1.16
  2026-04-17 10:40 256265 2026-04-17 10:44:59 2026-04-17 10:45:00.168 1.17
  2026-04-17 10:45 256265 2026-04-17 10:49:59 2026-04-17 10:50:00.176 1.18
  2026-04-17 10:50 257801 2026-04-17 10:54:59 2026-04-17 10:55:00.174 1.17
  2026-04-17 10:55 260105 2026-04-17 10:59:59 2026-04-17 11:00:00.178 1.18
  2026-04-17 11:00 260105 2026-04-17 11:04:59 2026-04-17 11:05:00.179 1.18
  2026-04-17 11:05 257801 2026-04-17 11:09:59 2026-04-17 11:10:00.177 1.18
  2026-04-17 11:10 260105 2026-04-17 11:14:59 2026-04-17 11:15:00.178 1.18
  2026-04-17 11:15 260105 2026-04-17 11:19:59 2026-04-17 11:20:00.177 1.18
  2026-04-17 11:20 256265 2026-04-17 11:24:59 2026-04-17 11:25:00.175 1.18
  2026-04-17 11:25 256265 2026-04-17 11:29:59 2026-04-17 11:30:00.183 1.18
  2026-04-17 11:30 260105 2026-04-17 11:34:59 2026-04-17 11:35:00.189 1.19
  2026-04-17 11:35 256265 2026-04-17 11:39:59 2026-04-17 11:40:00.209 1.21
  2026-04-17 11:40 260105 2026-04-17 11:44:59 2026-04-17 11:45:00.198 1.2
  2026-04-17 11:45 256265 2026-04-17 11:49:59 2026-04-17 11:50:00.200 1.2
  2026-04-17 11:50 257801 2026-04-17 11:54:59 2026-04-17 11:55:00.445 1.45
  2026-04-17 11:55 256265 2026-04-17 11:59:59 2026-04-17 12:00:00.202 1.2
  2026-04-17 12:00 257801 2026-04-17 12:04:59 2026-04-17 12:05:00.194 1.19
  2026-04-17 12:05 257801 2026-04-17 12:09:59 2026-04-17 12:10:00.432 1.43
  2026-04-17 12:10 256265 2026-04-17 12:14:59 2026-04-17 12:15:00.187 1.19
  2026-04-17 12:15 257801 2026-04-17 12:19:59 2026-04-17 12:20:00.433 1.43
  2026-04-17 12:20 257801 2026-04-17 12:24:59 2026-04-17 12:25:00.430 1.43
  2026-04-17 12:25 256265 2026-04-17 12:29:59 2026-04-17 12:30:00.176 1.18
  2026-04-17 12:30 256265 2026-04-17 12:34:59 2026-04-17 12:35:00.175 1.18
  2026-04-17 12:35 260105 2026-04-17 12:39:59 2026-04-17 12:40:00.185 1.19
  2026-04-17 12:40 256265 2026-04-17 12:44:59 2026-04-17 12:45:00.187 1.19
  2026-04-17 12:45 256265 2026-04-17 12:49:59 2026-04-17 12:50:00.190 1.19
  2026-04-17 12:50 257801 2026-04-17 12:54:59 2026-04-17 12:55:00.187 1.19
  2026-04-17 12:55 260105 2026-04-17 12:59:59 2026-04-17 13:00:00.186 1.19
  2026-04-17 13:00 260105 2026-04-17 13:04:59 2026-04-17 13:05:00.190 1.19
  2026-04-17 13:05 260105 2026-04-17 13:09:59 2026-04-17 13:10:00.187 1.19
  2026-04-17 13:10 256265 2026-04-17 13:14:59 2026-04-17 13:15:00.184 1.18
  2026-04-17 13:15 260105 2026-04-17 13:19:59 2026-04-17 13:20:00.180 1.18
  2026-04-17 13:20 260105 2026-04-17 13:24:59 2026-04-17 13:25:00.178 1.18
  2026-04-17 13:25 257801 2026-04-17 13:29:59 2026-04-17 13:30:00.180 1.18
  2026-04-17 13:30 260105 2026-04-17 13:34:59 2026-04-17 13:35:00.175 1.18
  2026-04-17 13:35 260105 2026-04-17 13:39:59 2026-04-17 13:40:00.185 1.18
  2026-04-17 13:40 257801 2026-04-17 13:44:59 2026-04-17 13:45:00.424 1.42
  2026-04-17 13:45 256265 2026-04-17 13:49:59 2026-04-17 13:50:00.185 1.18
  2026-04-17 13:50 260105 2026-04-17 13:54:59 2026-04-17 13:55:00.439 1.44
  2026-04-17 13:55 260105 2026-04-17 13:59:59 2026-04-17 14:00:00.442 1.44
  2026-04-17 14:00 256265 2026-04-17 14:04:59 2026-04-17 14:05:00.192 1.19
  2026-04-17 14:05 256265 2026-04-17 14:09:59 2026-04-17 14:10:00.194 1.19
  2026-04-17 14:10 256265 2026-04-17 14:14:59 2026-04-17 14:15:00.202 1.2
  2026-04-17 14:15 260105 2026-04-17 14:19:59 2026-04-17 14:20:00.197 1.2
  2026-04-17 14:20 260105 2026-04-17 14:24:59 2026-04-17 14:25:00.182 1.18
  2026-04-17 14:25 260105 2026-04-17 14:29:59 2026-04-17 14:30:00.178 1.18
  2026-04-17 14:30 260105 2026-04-17 14:34:59 2026-04-17 14:35:00.174 1.17
  2026-04-17 14:35 256265 2026-04-17 14:39:59 2026-04-17 14:40:00.171 1.17
  2026-04-17 14:40 256265 2026-04-17 14:44:59 2026-04-17 14:45:00.171 1.17
  2026-04-17 14:45 260105 2026-04-17 14:49:59 2026-04-17 14:50:00.168 1.17
  2026-04-17 14:50 257801 2026-04-17 14:54:59 2026-04-17 14:55:00.417 1.42
  2026-04-17 14:55 257801 2026-04-17 14:59:59 2026-04-17 15:00:00.173 1.17
  2026-04-17 15:00 260105 2026-04-17 15:04:59 2026-04-17 15:05:00.172 1.17
  2026-04-17 15:05 256265 2026-04-17 15:09:59 2026-04-17 15:10:00.171 1.17
  2026-04-17 15:10 256265 2026-04-17 15:14:59 2026-04-17 15:15:00.420 1.42
  2026-04-17 15:15 256265 2026-04-17 15:19:59 2026-04-17 15:20:00.423 1.42
  2026-04-17 15:20 256265 2026-04-17 15:24:59 2026-04-17 15:25:00.172 1.17
  2026-04-17 15:25 256265 2026-04-17 15:29:59 2026-04-17 15:30:00.429 1.43
  2026-04-17 15:30 256265 2026-04-17 15:34:59 2026-04-17 15:35:00.427 1.43
  2026-04-17 15:35 260105 2026-04-17 15:39:59 2026-04-17 15:40:00.204 1.2
  2026-04-17 15:40 256265 2026-04-17 15:44:59 2026-04-17 15:45:00.437 1.44
  2026-04-17 15:45 256265 2026-04-17 15:49:59 2026-04-17 15:50:00.437 1.44
  2026-04-17 15:50 256265 2026-04-17 15:54:59 2026-04-17 15:55:00.188 1.19

[Stillness]

Not only in API, data is delayed by 1 second in Kite app and web too. I was skeptical, now I am confident.

[bkt]

Anyone else facing similar issue?

[TheQuantBros]

I think, this isn’t a latency issue, it’s how candles are being finalized.

Candles should be built using tick timestamps, not local time, and you shouldn’t close them immediately when the next second starts.

Just keep the previous candle open briefly and allow late ticks to update it — otherwise you’ll miss the actual closing tick.

Adding delay is just a workaround, proper handling is letting candles accept late ticks before finalizing.

Use vps (mumbai server) u can get around 100-500ms

[bkt]

I’m building candles using tick timestamps.

The issue is - the last tick arrives during the start of the next interval. Delay or handling, the issue remains the same. Either way, you have to wait for the tick to arrive. Correct me if I’m wrong here.

I’m on DigitalOcean and unfortunately they don’t have a server in Mumbai. I’m using the one in Bangalore. Also, I noticed Kite uses CloudFlare Edge, so not sure if network latency should be an issue. Ping results also show 5ms maximum latency which is negligible.

[TheQuantBros]

Yes, agreed — you still have to wait for the tick to arrive, that part is unavoidable.

The difference is not about avoiding the wait, but about how the candle is handled during that time. If the system closes the candle immediately, it will miss late ticks. If it allows the previous candle to accept late ticks, the OHLC stays correct.

So the issue isn’t the delay itself, it’s whether the candle is being finalized too early.

And yeah, with ~5 ms ping and Cloudflare in between, this looks more like feed-side timing than network latency — VPS may help a bit but won’t eliminate it.

[nivas_k]

Each tick includes an exchange timestamp, which reflects when the trade or quote actually occurred at the exchange. For any time-based aggregation like candles, this timestamp is the correct reference, rather than the local system time when the tick is received.

On our end, ticks are forwarded immediately as we receive them, without any intentional delay, batching, or buffering. However, once the data is sent to your system over WebSocket, it travels across the internet. During this stage, small delays can occur due to network conditions, routing paths, and other factors outside the control of any single participant.

So while the data itself remains accurate, the arrival time at your system can be slightly later than the exchange timestamp.

To handle this reliably, you may consider event-driven bar completion logic instead of strict wall-clock cutoffs, so late-arriving ticks are included in the correct interval.

[bkt]

How much delay should we expect in receiving ticks if our server is in Bangalore and ping is < 20ms consistently for WebSocket endpoint?

When you receive ticks from the exchange, how much delay you expect at your end? Do you have any analysis done at your end that you can share with me please?

As mentioned earlier, my issue is not about how should I construct the bar reliably (thank you for the event driven suggestion though - looks neat option, I might save 200-250ms). But the core issue remains - the ticks are arriving late. This means the last tick that I receive is delayed by almost 500-750ms causing it to arrive at the start of the next 5 minute interval. This is consistent observation. Check the analysis I shared above. This is clearly suggesting a WebSocket delay at your end. Doesn’t look like network latency issue at my end. Here’s the data:

• REST API (api.kite.trade): sub-millisecond to ~3 ms RTT, zero loss — Cloudflare-fronted, effectively terminated at the Bangalore edge.
• WebSocket (ws.kite.trade): ~16–18 ms TCP RTT to the AWS Mumbai (ap-south-1) ELB — this is the expected Bangalore↔Mumbai inter-region latency.

There is no measurable network-side latency contributing to tick delays from our side. Any tick-arrival jitter beyond ~18 ms is upstream of our TCP socket.

[nivas_k]

Market data delivery involves multiple stages (exchange → vendor/feed handlers → distribution → internet → client), and latency can accumulate across this pipeline. Even in well-optimized systems, this can result in hundreds of milliseconds of variation in tick arrival times.

From our side, we relay ticks as and when they are received from the exchange; there is no intentional throttling, batching, or delay introduced at our end.

That said, it’s important to set the right expectation here:

• Kite Connect is not designed for latency-sensitive or HFT-style strategies.
• In all retail setups globally, some level of data latency is inherent when operating over the internet
• If a strategy depends on low-latency precision, the typical approach is co-location, where infrastructure is physically closer to the exchange.

In practice, delays in the few-hundred-millisecond range are not unusual for internet-based retail market data APIs.

[KaranRohra]

How would we handle bar-based completion logic in illiquid scripts or circuits in which candle calculation might get delayed? Can you suggest an approach to handle this case?