Thanks — I’m responding to your question about what

e2e_latency

means in that log line. In this log,

e2e_latency

stands for “end-to-end latency.” It measures the total elapsed time for the voice-agent round trip: from when the user finished speaking (

stopped_speaking_at

) to when the agent’s response was produced/delivered. In your log the value is 14.271479606628418 seconds, so the full round trip took about 14.27 seconds. What the metric normally includes • End-of-utterance detection and any queuing delay after the user stops speaking. • Speech-to-text (STT) processing time (if applicable). • Language model (LLM) processing and response generation time. • Text-to-speech (TTS) generation and any streaming/playback time. • Network or system delays between components. Why this matters • Shorter e2e latency makes conversations feel natural. Typical goals are in the 2–3 second range for interactive voice agents; 14+ seconds indicates something is slowing the pipeline (long generation, slow TTS, network delays, or extra processing). Helpful next steps to diagnose the cause • Check the individual timing fields you already have: ◦

llm_node_ttft

(Time To First Token from the LLM) ◦

tts_node_ttfb

(Time To First Byte from the TTS engine) Compare those to

e2e_latency

to see which stage is contributing most time. • Look for additional timestamps such as when the request was sent to the LLM, when the LLM finished, and when TTS finished/started playback. • If you’d like, share the other related timestamps or the full metric block and I can help pinpoint which stage is the largest contributor. Sources: Streamline troubleshooting with Agent Observability | examples/frontdesk | livekit/livekit_composite | DeepWiki