Incorrect/false high e2e Latency > 203 seconds OR sometimes not present at all in chat item

Getting Started
, , ,
1

We’ve noticed that for some rooms the reported E2E latency is either extremely high (often >200 seconds) or missing entirely.

From reviewing the session recordings, there does not appear to be any actual user-visible delay. The high E2E latency values seem to be driven by unusually large transcription_delay and end_of_turn_delay metrics.

Example metric payload:

{
  "started_speaking_at": "2026-06-12T18:52:03.881Z",
  "stopped_speaking_at": "2026-06-12T18:48:40.647Z",
  "transcription_delay": 203.2745988368988,
  "end_of_turn_delay": 203.40400671958923,
  "on_user_turn_completed_delay": 0.00006804399890825152
}

Examples of sessions with unusually high E2E latency:

  • Session: RM_8QjN2S9pRA4m — timestamp 8:10.88

  • Session: RM_5CcWSoM77Npx — timestamp 9:13.26

  • Session: RM_vrwpheZtBoDx — timestamp 8:07.65

  • Session: RM_8GAcHsSvxCkq — timestamp 8:53.57

Examples of sessions where E2E latency data is missing:

  • Session: RM_8GAcHsSvxCkq

    • 7:25.12

    • 6:24.22

    • 5:04.62

    • 4:03.84

    • and several other timestamps within the same session

Could you help investigate why these latency values are either being reported incorrectly or are missing?

For analytics, we currently rely primarily on metrics such as TTSFB and LLM TTFT, so we’d like to better understand the reliability of the E2E latency calculation.

For STT, we’re using a custom Deepgram provider with our own API key. The model is nova-3-medical via the LiveKit Deepgram SDK with the following endpoint configuration:

deepgram/v1/listen?model=nova-3-medical&punctuate=true&smart_format=true&no_delay=true&interim_results=true&encoding=linear16&vad_events=true&sample_rate=16000&channels=1&endpointing=100&filler_words=true&profanity_filter=false&numerals=false&mip_opt_out=false&language=en-GB

Current versions:

livekit-agents==1.6.0
livekit-plugins-deepgram==1.6.0
livekit-plugins-turn-detector==1.6.0
2

I don’t believe you have shared those sessions with support? (I only tried the first one). Can you please share them as detailed here:

I also see your support ticket in the system (just mentioning to avoid duplicating effort).

For STT, we’re using a custom Deepgram provider with our own API key.

I suspect this will be critical to understand the latency. Just to clarify, you’re not just using the plugin at Deepgram STT | LiveKit Documentation, you have a custom implementation that integrates with Deepgram using Websockets?

3

All sessions are shared with livekit support and i am using livekit deepgram STT plugin as mentioned in docs. not custom implementation

4

Looking at RM_5CcWSoM77Npx those high values are caused because the stopped_speaking_at happens AFTER the started_speaking_at, and 203 seconds is the absolute value between those two.

Working back I see a warning in the logs about input is shorter by 81880 samples..., which seems to correspond with the stopped_speaking_at time (3.4 mins earlier).
I also see a similar pattern for your RM_vrwpheZtBoDx session.

This usually means there was some issue with the user’s mic track, agents/livekit-agents/livekit/agents/voice/recorder_io/recorder_io.py at main · livekit/agents · GitHub, but I can’t say exactly what - there’s nothing in the server logs from around that time.

5

Thanks, i think solution was merged fix(voice): skip end-of-turn metrics on stale/out-of-order speaking anchor by anshulkulhari7 · Pull Request #6098 · livekit/agents · GitHub

I hope it will be released soon.

6

That’s great, I see internal discussions that 1.6.1 might happen today, but if not today, then it will be soon.