Voice metrics and latency

​

How Tuner measures a call

A single end-to-end latency number hides where the time went. Tuner breaks each turn of the conversation into its pipeline stages and shows the timing per turn, per stage and across the call. You read it in two places on the call details page:

• The transcript: latency badges on each turn.
• The Voice Metrics tab: response time at p50 and p90, latency by stage, the longest agent monologue and, on replay calls, transcription accuracy.

​

Pipeline stages

Every agent response passes through four stages, each measured on its own: EOU, STT, LLM and TTS. The stages overlap in real time. Speech-to-text runs while the customer is still talking, and endpointing runs alongside transcription. Because of this, the stage timings don’t add up to the total response latency. The Voice Metrics tab shows each stage as its own bar on a shared time axis so you can compare them.

​

Read the stage breakdown

For each stage, the Voice Metrics tab draws a bar from p50 to p90 on a shared time axis:

• p50 (median): the typical turn for that stage.
• p90 (90th percentile): the slow tail. Nine out of ten turns were faster than this.

The length of each bar matters as much as its position. A stage that sits at 300 ms at p50 but reaches 900 ms at p90 is inconsistent, and that is often a bigger problem than a stage that is steadily slow. A short bar means the stage is predictable. A long one means something makes it spike, so look there first. If the call has no per-stage data, the tab shows “Stage latency not available for this call.” To see whether a change, like a new speech-to-text provider or model, made a stage faster, replay the same Dataset calls before and after it. The caller audio is identical on every run, so any difference comes from your change.

​

TTFB: time to first byte

TTFB is the delay the customer experiences: the time from the end of the customer’s speech to the start of the agent’s speech. TTFB is measured directly. It isn’t the sum of the four stages, which overlap. The stage breakdown explains where the delay came from by showing which stage was slowest and which varied most. Under TIME TO FIRST BYTE, the tab shows TTFB p50 and TTFB p90, each with a rating: A good p50 with a slow p90 means most turns are fine but some are much slower, often because of a few slow tool calls or long model turns. The call header also shows TTFB P50 and TTFB P90.

​

Per-turn latency in the transcript

The transcript shows latency badges on each turn, so you can see where in the conversation the delay happened. Hover over a badge to see what it measures.

​

Agent turns

An agent turn that the customer cut off is marked Interrupted.

​

Customer turns

​

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. Expand it to see which nodes were entered. This helps with agents built on graph-based or stateful workflows: you can see when the agent changed state and compare it with any change in latency.

​

Tool calls

When the agent calls a tool, a row appears in the transcript at the moment of the call, with the tool name and how long it took. Expand it to see the Input and the Output (or Error). Tool time falls inside the LLM stage for that turn, so if a turn has a high LLM value, check its tool calls first.

​

Provider variation

The stages available, and how precise they are, depend on your voice platform and stack. Not every platform reports all four stages separately. Some report only a combined latency, and EOU is only available from stacks that report it, such as the Tuner LiveKit and Pipecat SDKs. When a stage isn’t reported, Tuner leaves it out of the breakdown instead of showing it as zero. If a turn shows only a Latency badge, your platform isn’t reporting per-stage timing for that turn.

​

Conversation metrics

Under CONVERSATION, the tab shows Longest agent monologue: the longest uninterrupted agent response in the call. Long monologues make it more likely that the customer disengages. Other call-level signals, such as sentiment, are captured as data extraction fields. See Predefined evals for what Tuner checks out of the box.

​

Transcription accuracy

Transcription accuracy shows how well your agent’s speech-to-text heard a replayed caller. Tuner compares the reference transcript of each caller turn in the Dataset call with what your agent’s transcript shows the caller said, and scores the difference as a word error rate. The card appears at the top of the Voice Metrics tab, on calls from a replay only. Tuner scores the call once it ends.

​

Read the card

If your agent’s call ended before every caller turn played, the card says Call ended early and how many turns were scored, for example scored 3 of 5 turns. The score is the share of reference words that aren’t misheard, missed or added. Tuner compares all the caller turns that played against everything your agent transcribed from the caller as one text, so where your agent’s speech-to-text splits the audio doesn’t matter. It ignores case, punctuation and filler words like “um” and “uh”, and it treats numbers, symbols and currencies written differently as the same words.

​

Ratings

​

Verification line

The score is only as good as the reference transcripts. Tuner writes a draft transcript for each caller turn when you add the call. You can edit and verify each one. The line under the score shows where you are: The links open the Dataset call, where you verify the transcripts.

​

Outdated scores

When you edit, verify or unverify a transcript after a call was scored, the card shows an Outdated badge. Editing never recalculates a call on its own. Click Recalculate to score the call again against the current transcripts. The card then shows the new score.

​

Calls that aren’t scored

Tuner shows no card on a call that isn’t a replay. For a replay it can’t score, the card says why.

​

Limits

You can recalculate a call through the public API: see Recalculate Transcription Accuracy in the calls group of the API Reference.

​

Going deeper with traces

The stage breakdown tells you which stage of a turn was slow. It doesn’t tell you what ran inside that stage. If your agent is built on LiveKit Agents or Pipecat, you can send its OpenTelemetry spans to Tuner and get a span tree per call, showing the model request, the synthesis stream and each tool call, with the timing of each. The call then has a Traces tab. Voice metrics measure the latency your customer perceived, on every call, with no setup. A trace shows the operations that produced that latency, and needs a one-time exporter change in your agent. See OpenTelemetry Traces.

​

Next steps