> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetuner.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Voice metrics and latency
> Tuner breaks every call into individual turns and measures the latency of each pipeline stage — EOU, STT, LLM, and TTS — so you can pinpoint exactly where time is being spent and what is causing delays.
**No setup required.** Per-turn latency and voice metrics are captured automatically for every call as soon as your agent is integrated with Tuner — no additional configuration needed.
## How Tuner Measures a Call
Most voice AI platforms give you a single end-to-end latency number. That number hides the problem. Tuner decomposes every turn in the conversation into its pipeline stages and shows you where time actually went — per turn, per stage, and across the full call.
Two views surface this:
* **The Transcript** — per-turn latency badges inline with each message
* **The Voice Metrics panel** — latency broken down by stage, with p50 and p90 shown side by side, plus a conversation summary
***
## The Pipeline Stages
Every agent response passes through four stages, each measured independently: **EOU**, **STT**, **LLM**, and **TTS**.
These stages are **not** strictly sequential — they overlap in real time. Speech-to-text streams while the customer is still talking; endpointing runs concurrently with transcription. Because of this overlap, the stage timings do **not** add up to the total response latency, and Tuner never presents them as slices of a single bar. Each stage is a measurement in its own right, shown on a shared time axis so you can compare them directly.
### EOU — End of Utterance
The time the system waits, after the customer stops speaking, before it decides the turn is actually over and the agent can begin responding. This is endpointing delay — the pause between the customer finishing and the pipeline committing to "they're done."
**Typical range:** 300–800ms, depending on your endpointing model and its sensitivity. Semantic or model-based endpointing trades a little latency here for fewer mid-sentence interruptions.
**What to look for:** High EOU on a turn where the customer paused mid-thought usually means the endpointer waited through a silence timeout rather than detecting the end confidently. Consistently high EOU across the call points at conservative endpointing configuration — the agent feels slow to respond even when the rest of the pipeline is fast.
### STT — Speech-to-Text
The time from the end of the customer's speech to when the transcript is ready for the LLM. The customer's audio travels through your STT engine and is transcribed before any processing can begin.
**Typical range:** 100–600ms. Spikes here usually indicate provider-side transcription latency or network overhead between your infrastructure and the STT service.
**What to look for:** Consistently high STT on every turn suggests the STT provider or network path is the bottleneck. High STT on specific turns only often means the utterance was long or the audio quality was poor.
### LLM
The time attributed to the model on this turn — reasoning, prompt processing, and any tool calls made while generating the response.
The exact measurement (time to first token vs. full generation time) currently varies by integration. See your framework's integration page for specifics.
**Typical range:** 200ms–1s+, depending on model, context length, and whether tools were called.
**What to look for:** LLM time growing across a conversation signals context accumulation — as the history grows, the model takes longer to process it. A single turn with unusually high LLM time often means a tool call was made or a long system prompt was processed.
### TTS — Text-to-Speech
The time from when the first token arrives to when the first audio chunk is playing back to the customer. The generated text is sent to your TTS engine, which synthesizes speech and streams it back.
**Typical range:** 50–300ms. TTS is usually the smallest contributor to overall latency.
**What to look for:** High TTS is less common but can indicate TTS provider latency or network issues. Very low TTS with high overall latency means the bottleneck is elsewhere.
***
## Reading the Stage Breakdown
For each stage, the Voice Metrics panel shows a **range from p50 to p90** on a shared time axis:
* **p50** (median) — the typical case for that stage
* **p90** (90th percentile) — the tail; nine out of ten turns were faster than this
The **length** of each range is as informative as its position. A stage that sits at 300ms at p50 but stretches to 900ms at p90 has a wide spread — it's *inconsistent*, and that inconsistency is often a bigger problem than a stage that's steadily slow. A short range means the stage is predictable; a long one means something makes it occasionally spike, which is where to look first.
Because every stage shares the same axis, you can see at a glance which stage is both the slowest and the most variable — usually the LLM stage, and usually driven by variable generation length or tool calls.
***
## TTFB — Time to First Byte
**TTFB** (Time to First Byte) is the end-to-end delay a customer actually experiences: the time from the moment they stop speaking to the moment they hear the agent's first audio.
TTFB is **not** the arithmetic sum of the four stages. Because the stages overlap in real time, adding them would overstate the real delay. TTFB is measured directly as the perceived gap, and the stage breakdown explains *where* that gap comes from — not by summing to it, but by showing which stage dominated and which was most variable.
The panel shows TTFB as two headline numbers — **p50** and **p90** — each with a quality label (**Good**, **Fair**, or **Slow**). Showing both at once is deliberate: a good p50 with a bad p90 means most turns are fine but a fraction are badly slow, typically caused by a few high-latency tool calls or long model-reasoning turns. That split is the single most common latency signature, and you read it in one glance instead of toggling.
***
## Per-Turn Latency in the Transcript
The transcript shows latency badges on every turn so you can see exactly where in the conversation latency occurred.
### Agent turns
| Badge | What it measures |
| ----------- | --------------------------------------------------- |
| **Latency** | Total TTFB for this turn |
| **LLM** | Time attributed to the model on this turn |
| **TTS** | Time to synthesize and stream the first audio chunk |
### Customer turns
| Badge | What it measures |
| ------- | --------------------------------------------------------- |
| **EOU** | Endpointing delay before the turn was considered complete |
| **STT** | Time to transcribe this utterance |
### Node Transitions
When the agent moves between workflow nodes, a **Node Transition** row appears in the transcript between the customer's message and the agent's response. It shows which node was entered and how many transitions occurred. This is particularly useful for agents built on graph-based or stateful workflow systems — you can see exactly when the agent changed state and correlate it with any change in latency.
### Tool Calls
When the agent invokes a tool, it appears as an inline row in the transcript at the exact timestamp it was called. The row shows the **tool name**, **execution time**, and can be expanded to inspect arguments and the response. Tool execution time falls inside the LLM window for that turn — so if a turn has an unusually high LLM value, expanding any tool calls is the first place to look.
***
## Provider Variation
The exact stages available and their precision vary by voice provider and stack. Not every provider exposes all four stages separately — some report only a combined latency figure, and endpointing (EOU) in particular is only available from stacks that emit it (for example, our LiveKit and Pipecat SDKs).
When a stage isn't reported, Tuner shows what it has and omits what it doesn't — a stage with no data is left out of the breakdown rather than shown as zero, which would falsely imply the stage was instant. If a turn shows only a single **Latency** badge with no per-stage breakdown, your provider isn't reporting per-stage timing for that turn.
***
## Conversation Metrics
Alongside latency, the Voice Metrics panel surfaces one conversation-shape metric:
| Metric | What it measures |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Longest agent monologue** | The longest uninterrupted agent response in the call. Long monologues increase the chance of customer disengagement. |
Other call-level signals, such as sentiment, are captured separately as data-extraction fields rather than voice metrics. See [Introduction to Pre-defined Metrics](/docs/evaluation/predefined-evals) for the full catalog of what Tuner computes out of the box.
***
### Next Steps
The 21 evals Tuner ships with, and what each one checks.
How to use the transcript, events, and metrics together to debug a specific call.
