Skip to main content
Start from the symptom. Each section below covers one common complaint and the signals to check for it, using the same data Daily’s support team uses. Grab the session ID for the affected call first. Every check below is easier with it. See finding your session ID.

​
Start with the session in the dashboard

The Daily dashboard shows call quality data for every session on your domain. The dashboard overview has screenshots.
1

Open the session

On the Sessions page, find the session by session ID, room name, or time.
2

Find the affected participant

The session view lists every participant with their packet loss and join time. Click the one who reported the problem.
3

Read their charts and event log

The participant view shows their browser, OS, and network type, packet loss and bitrate charts for the whole session, and a full event log from their point of view.
Scan the packet loss and bitrate charts first, then the event log for videoQualityLimReason, cpu load state change, network-connection interruptions, and Connection downlink. The logging and metrics guide explains each log line and metric, including how to tell a network cause from a CPU one. Keep it open alongside this page.

​
”I couldn’t join the call”

Work through these in order:
  1. Check the room URL and token. The error event says why a join was rejected. Common types: no-room (bad URL or deleted room), exp-room / exp-token (expired), nbf-room / nbf-token (not valid yet), not-allowed (private room without a valid token), and meeting-full.
  2. Look for connection-error. That error type means the network path failed, not the room. details.on names the step: load, room-lookup, join, reconnect, move, or rtc-connection.
  3. Suspect the network. Corporate firewalls and VPNs can block the WebSocket or UDP connections a call needs. Run testWebsocketConnectivity() first: a failed result means the call can’t get started on that network. Then run testNetworkConnectivity() to check whether a TURN connection works. The firewall and allowed IP guide lists what to unblock.
  4. Run a full pre-call test. testCallQuality() streams real media to Daily for up to 30 seconds and returns a verdict. The network and call quality guide covers all the pre-call tests.
A user who never reaches Daily’s servers has no session and nothing in the dashboard. Their browser console is your only evidence. Capture it.

​
”I couldn’t select my camera or microphone”

Device failures fire the camera-error event. daily-js normalizes the browser’s inconsistent errors, so the same root cause gives the same error.type on every browser: The device permissions guide covers these errors and how to build a UI that helps users recover.
Don’t call getUserMedia() yourself to get the camera or mic. daily-js calls it internally to handle cross-browser edge cases and to log the call in the session logs that make debugging possible. Calling it yourself causes microphone and camera problems for users. Let daily-js manage devices: select them with setInputDevicesAsync({ audioDeviceId, videoDeviceId }), and control them with startCamera(), setLocalAudio(), and setLocalVideo(). Passing your own MediaStreamTrack as audioSource or videoSource is for custom processing only, and your app then owns that track’s lifecycle.

​
”I couldn’t hear or see the other person”

First find out whether the problem is on their end, your end, or the path between. The dashboard lets you compare both participants in the same session.
  • Check the sender first. Open the other person’s participant page. Was their mic or camera on? Did their charts show packet loss or videoQualityLimReason entries? If the sender’s uplink struggled, everyone in the call had the same problem with them.
  • Then check the receiver. If the sender looks clean, open the reporter’s page. High receive-side packet loss means their downlink: usually wifi or their ISP.
  • Watch for one-way patterns. Media flowing one way but not the other points at a network path or firewall on one side, not a device.
In your app, network-quality-change and getNetworkStats() expose the same signals live. networkStateReasons says whether send packet loss, receive packet loss, round-trip time, or available bandwidth is the problem. Non-network causes to rule out:
  • The sender’s mic was muted, or captured silence because the wrong input device was selected.
  • A Bluetooth headset switched profiles mid-call, which can drop audio or make it muffled.
  • The sender’s device was under heavy CPU load. Look for cpu load state change in their event log, or listen for cpu-load-change in your app.

​
”They couldn’t hear or see me”

Same problem, opposite direction. Now you are the sender, so check your own side first:
  • Confirm your mic was live. startLocalAudioLevelObserver() emits local-audio-level events you can use for a mic level meter, so users can see their mic working before and during a call.
  • Check your participant page for send-side packet loss and videoQualityLimReason entries. bandwidth means your uplink couldn’t keep up. cpu means your device couldn’t.
  • Wifi upload speeds are often far worse than download speeds. A user with “fast internet” can still have a weak uplink. A wired connection is the quickest test.

​
”I got disconnected”

Every call uses two connections: signaling (call management) and sfu (audio and video). network-connection fires when either one is interrupted or recovers.
  • An sfu interruption pauses media and reconnects on its own. Users see a freeze, then recovery.
  • A signaling interruption is more serious. The client retries twice, and if both retries fail the call ends with an error event (type: 'connection-error') followed by left-meeting. There is no fixed deadline: how long the retries take depends on how the connection fails. Separately, the server drops a participant it has heard nothing from for about 35-40 seconds, so others may still see them during a long interruption.
In the dashboard event log, wss is stale lines and network-connection interrupted events mark these drops. Repeated drops over a short period mean an unstable network or an overloaded CPU. Clean packet loss charts plus repeated interruptions point at CPU. The logging and metrics guide shows how to tell the two apart.

​
Capture evidence while it’s happening

If you can reproduce the problem, capture two things first. The browser console. Save the full console from the affected user’s browser, including red errors and the messages around them. For far richer console output, turn on daily-js debug logging. Run this in the console, then reload the page:
daily-js then logs its internal activity to the console for every call on that page. To turn it off, run localStorage.removeItem('debug'). A screen recording with a visible clock. A recording that shows the problem (the frozen tile, the error message) next to a wall-clock time lets you line it up with the dashboard event log. Then gather the rest of the pre-support checklist so a support ticket, if you need one, gets answered in one round trip.