Voice observability

A voice call is a trace

Voice observability captures each voice call as a trace, the same tree of spans you get from a text app. One call becomes one trace, and each back-and-forth turn is a span inside it. The call carries the transcript, the recording, and its duration, turn count, and cost. A spoken conversation lands in the same place as every other request, ready for the same evals, alerts, and filters.

Inside a voice call

A turn is more than a single step. In an app you instrument on LiveKit or Pipecat, a turn’s span breaks down into speech-to-text, the model call, and text-to-speech, so you can see exactly where a turn went wrong, not just that it did. Managed calls arrive at the turn level, and the transcript and recording sit on the call either way.

flowchart TD
accTitle: What a voice call looks like as a trace
accDescr: A voice call is one trace made of turn spans. In an instrumented app each turn breaks down into speech-to-text, the model call, and text-to-speech. The call carries the transcript, recording, turn count, and cost.
C["Voice call · one trace"] --> T1["Turn · span"]
C --> T2["Turn · span"]
T1 --> STT["speech to text"]
T1 --> LLM["model call"]
T1 --> TTS["text to speech"]
C --> M["Transcript · recording · turns · cost"]

Because it is an ordinary trace, a voice call fits the same observability model as your text traces.

How a call reaches Observe

A voice call reaches Observe by one of two paths. Whichever it takes, it lands as the same trace; what differs is who produces the spans.

Path	For	How spans are produced	What you write
Managed ingestion	Hosted agents on Vapi or Retell	Observe pulls the provider’s call logs	No code: connect the provider and turn observability on
Auto-instrumentation	Apps built on LiveKit or Pipecat	Your app emits a span per turn through traceAI	A few lines of traceAI setup

For the managed-ingestion setup, see Voice observability.

Debugging a call

Take a support line running on a Vapi assistant. Observe pulls each finished call in as its own trace, so you read it top to bottom and follow the conversation turn by turn. When a caller reports the agent misheard their order number, you open that one call, jump to the turn where it happened, and play the audio back, instead of guessing from a dashboard.

When to use

Reach for voice observability when what you are debugging is a spoken conversation: a caller who got the wrong answer, an agent that ran long, a call that cost more than it should. It also fits when you want those calls sitting alongside the rest of your traces, ready to score and monitor.

When the grain is wrong, reach elsewhere:

• A text or SDK app, not a voice one: instrument it directly and start at the quickstart
• Trends across many calls, not one: build a dashboard

Why it matters

Voice failures are the ones you hear about from a customer, not a log. A spoken call normally leaves nothing behind to inspect; capturing it as a trace changes that, so a complaint becomes a call you can open, read, and replay instead of a guess.

Keep exploring