Observability Overview

You can see everything a call does, in real time and after the call ends. ClutchCall Voice records each call’s signalling, media quality, and agent behaviour as they occur. It then folds this data into durable records. You can query, chart, and alert on these records. You do not need to run a metrics pipeline. Every view uses the same identifier: the call’s sid. The live-ops row, the per-segment trace, the one-row CDR, the quality score, and the traffic tally all use that one key. You can move from “what rings right now” to “why did this specific call sound bad” without a manual match of IDs across systems.

​

What you can see

​

Live call state

While a call is up, the engine streams each state transition to your operations screens. The transitions are: initiated, ringing, answered, held, resumed, transferred, and cleared. The engine pushes updates over the same low-latency transport that carries the media. Thus a wallboard shows the floor within a tick, not on a polling interval. Each live row shows the sid, the attached legs (a PSTN caller, a SIP deskphone, a browser softphone, an AI agent), and the current state. When an AI segment exists, the row also shows that an agent handles the call. The same event stream later becomes the per-segment trace. Thus the live view and the later query always agree.

​

Per-segment traces vs. one-row CDRs

These are two different grains of the same call. Each grain is best for different situations. A call trace records every lifecycle transition, grouped by sid. When a call transfers from an AI agent to a human, the trace shows two segments: the AI leg and the human leg. Each segment has its own timings. You can see how long the caller spent with the bot before the warm handoff. You can also see the timings of the human leg. Traces power agent timelines, wrap-up-to-ready analysis, and VDN flow reports. The system writes a CDR as one settled row when a call clears. The row has the start, answer, and clear timestamps, the total duration, the Q.850 clear reason mapped to a status, the negotiated codec, and the agent handler (if any). Export this record for billing and long-horizon reports. The trace and the CDR come from the same lifecycle events. Thus a CDR and its trace always agree at their two grains. See Call lifecycle for the transitions that build them.

​

Quality: MOS, jitter, and loss

The media plane measures packet loss and jitter for the media leg of every call. It uses the ITU-T G.107 E-model to compute an estimated MOS from these measurements. The score is stored with the call’s other records. Thus “sort my calls by worst audio quality” is a simple query, not a forensic exercise. The media plane computes the score from the same loss and jitter counters that it already tracks per call. Thus the score adds no cost at call time. The score is available the moment the call clears. See MOS, jitter & packet loss for how to read and use these numbers.

​

Per-tenant traffic

The engine attributes bytes and bandwidth to the workspace that generated them. The data is divided by modality. Voice media is counted per tenant and per call. This data rolls up into a Traffic & Bandwidth view. From this one view, you can see which workspace causes the load right now. You can also see the trend of a tenant’s voice traffic. This view shows load and cost for the same fleet that the CDRs describe.

​

Dashboards

Prebuilt production dashboards use the live state, traces, CDRs, quality, and traffic data. The dashboards include: all-calls and call-detail reports, live wallboards, agent timelines, VDN-flow and skill-drill views, and the traffic board. See Production dashboards to learn which dashboards to watch. That page also tells you which dashboards are polished and which are not complete yet.

​

When the summary isn’t enough

The records above tell you what happened. Sometimes you need to know why: a call sounds wrong, a transfer did not connect, or an agent talks over the caller. Then use the lower-level tools:

​

Related