Is there any way to programmatically query (via API or MCP server) all the data shown under the livekit dashboard session which shows things like packets lost for a given participant?
When diagnosing if a user bug report was due to network connectivity issues, that would be very useful.
It is a good suggestion and has been discussed. But currently that is not available.
@Benjamin_Lowe, CWilson’s right that the dashboard telemetry isn’t exposed via API today. The closest existing programmatic signal is per-participant ConnectionQuality events from the client SDKs (enum: Excellent / Good / Poor / Lost / Unknown) which fire on quality state changes:
participant.on(ParticipantEvent.ConnectionQualityChanged,
(quality: ConnectionQuality) => {
console.log(participant.identity, 'quality:', quality);
}
);
[ livekit/client-sdk-js …/Participant.ts ]
It’s qualitative not quantitative (no packet-loss numbers), but enough to correlate with bug reports if you log it to your own backend. For raw packet-loss / jitter / RTT, the underlying WebRTC getStats() is reachable via SDK internals but not officially exposed on the Participant API, so you’d be polling from your own client wrapper and shipping the data to your backend yourself.
I see thank you - I would love to be able to query this data so hope that feature comes in future.
Incidently @Muhammad_Usman_Bashir In the Javascript client SDK the avatar shows a icon showing connection strength over the avatar of the agent and the avatar of the user - do we expect those to always be in sync (equal to) the agent side ConnectionQualityChanged events? We noticed some oddity recently that one user always gets 1 bar of “signal” shown on the agent avatar, despite experiencing no problems with the call (and agent showing no issues when other users talk to the same worker node).
We currently log server side ConnectionQualityChanged events, but how do we log the initial connection quality? I see some cases where it seems that ConnectionQualityChanged never fires (like the prior session where my colleague saw locally poor agent connection strength throughout the call according to the client), so we have no log of the connection health server side as no ConnectionQualityChanged was emitted.
python
@property
def connection_quality(self) → ConnectionQuality:
“”"The participant’s most recently reported connection quality.
Returns \`\`ConnectionQuality.QUALITY_UNKNOWN\`\` until the first
connection-quality update is received. Updated automatically whenever a
\`\`connection_quality_changed\`\` event fires for this participant.
“”"
return self._connection_quality
We are also investigating adding the official livekit connection test Add connection check helper by lukasIO · Pull Request #489 · livekit/client-sdk-js · GitHub , but it takes up to 30 seconds to measure the jitter etc. so its challenging for us to think how best to fit it into the user journey without it being obtrusive
@Benjamin_Lowe, Two things.
The components-js ConnectionQualityIndicator reads participant.connectionQuality (the server’s per-participant view), so asymmetry is expected: one user’s stuck 1-bar is usually their endpoint (ISP packet loss, browser throttling, device under-reporting RTCP), not the agent. Other participants experiencing nothing wrong confirms that.
For the initial-quality logging gap: connection_quality returns QUALITY_UNKNOWN until first update, and updates only fire on changes. Poll on a timer:
import asyncio
async def log_initial_quality(participant, delay=5.0):
await asyncio.sleep(delay)
logger.info(
"initial_quality",
participant=participant.identity,
quality=participant.connection_quality,
)
@session.on("participant_connected")
def on_participant(p):
asyncio.create_task(log_initial_quality(p))
For the 30s connection check: it’s composable. Run individual fast checks (checkWebsocket, checkWebRTC) inline at session start, defer slower ones (checkTURN, checkReconnect) to background [ livekit/client-sdk-js …/ConnectionCheck.ts ].