Skip to main content
Latency Recorder gives your team a practical way to monitor how fast conversations feel to customers.
It turns each completed voice interaction into measurable latency signals that you can track in Dashboard V2.

​
What you can monitor

Dashboard V2 now exposes latency recorder call-level measures through the Conversations data source.
The values come from comm_latency_stats and are joined by communication_id under the hood.
MetricWhat it answers
agent_latencyHow long users wait before hearing the agent (communication-level latency metric)
agent_speech_percentageShare of call duration occupied by agent speech
human_speech_percentageShare of call duration occupied by human speech
For agent_speech_percentage and human_speech_percentage, Dashboard V2 uses weighted formulas in aggregation mode:
  • SUM(agent_speech_duration_ms) / SUM(total_call_duration) * 100
  • SUM(human_speech_duration_ms) / SUM(total_call_duration) * 100
This keeps percentages accurate under filters and groupings.

​
How to use it in Dashboard V2

  1. Create or edit a Dashboard V2 widget.
  2. Set Data source to Conversations.
  3. Pick a measure such as:
    • Average agent_latency
    • Average agent_speech_percentage
    • Average human_speech_percentage
  4. Set Slice by to start_date for day-over-day trends.
  5. Add filters (agent, channel, direction, status) to compare behavior across segments.
Dashboard viewPrimary metricWhy it is useful
Experience trendavg(agent_latency) by start_dateDetect overall responsiveness regression
Talk-balance trendavg(agent_speech_percentage) and avg(human_speech_percentage)Detect conversation balance drift over time
Agent comparisonavg(agent_latency) by agent_nameDetect specific agents with slower response patterns
Channel comparisonavg(agent_latency) by channelCompare responsiveness between voice/chat/email traffic

​
When to open turn-level detail

Dashboards are best for trend monitoring and alerting.
When a spike appears, move from the aggregated row to interaction-level investigation using communication_id. At that stage, use the persisted turn breakdown (latency_breakdown) to inspect:
  • Turn summaries (stop reason, timeout detection, tool calls)
  • Event timelines
  • Per-turn duration differences inside the same interaction