Skip to main content

Run history & traces

Every voice agent call lands in a dedicated Run history screen. Unlike text-agent runs, voice runs are continuous calls — so the run detail view is built around the call recording + transcript + trace, all synced together.

The run history list​

Open a voice agent and switch to Run history. Each call is shown as a run card.

Each run card shows:

  • Run ID
  • Start time
  • Total duration (seconds — the value used for billing)
  • Status — success / failed / partial
  • Mode — sync / async / realtime API

Clicking a run card opens the run detail view.

Conversation transcript​

The run detail view shows the full conversation as a turn-by-turn transcript. Each turn includes:

  • Speaker label — User or Agent.
  • Timestamp within the call.
  • Transcribed text — for User turns this is the STT output; for Agent turns this is the text that was synthesized to speech.

The run header summarizes total call duration.

Trace and span view​

The run detail view includes a hierarchical trace representing pipeline spans. The top-level span is the full call. Child spans represent pipeline steps within each turn.

Each span shows:

  • Span name
  • Start offset from call start
  • Duration
  • Status

The trace always includes these spans:

  • STT processing wait time — also carries the user's transcribed utterance as an attribute.
  • TTS generation wait time — also carries the agent's response text that was synthesized.
  • LLM reasoning
  • Tool execution — one span per tool call.

When a fallback STT or TTS provider was used for a turn, the corresponding span carries a provider_fallback_used: true attribute so you can quickly spot fallback events.

The trace also includes the latency telemetry metrics described in Voice latency — TTFS, queue wait, silence gap rate.

Audio playback synced to the trace​

You can play the call recording from the run detail view. As the audio plays, both the transcript and the waterfall auto-scroll to show the corresponding span/utterance at that point in time. This makes it straightforward to correlate what the user actually heard with what was happening in the pipeline — useful for diagnosing perceived hesitation, wrong voice output, or transcription errors.

Common debugging patterns​

  • Long Time-to-First-Speech (TTFS). Open the trace, look at STT processing wait time and TTS generation wait time. Use Voice latency for aggregate P90/P99.
  • Wrong transcription. Read the STT span's transcript attribute. If the user's words were mis-transcribed, consider tuning keyterms, endpointing, or switching the model — see Transcriber (STT) configuration.
  • Voice cut off mid-sentence. Check whether a fallback voice was triggered partway. The platform deliberately does not switch fallback voices after 3 seconds of audio playback in a single turn to avoid jarring voice changes.
  • Hesitation after a tool call. Look at the gap between the Tool execution span end and the next LLM span start. In Sync mode this should be near-zero.

Run history evaluation​

You can run evaluators directly against voice run transcripts. See Voice Agent evaluation.