Skip to main content
Daily’s support team investigates by looking up the exact session and reading its logs and metrics. The biggest cause of slow tickets is a report that doesn’t identify the session. Here is what to collect, and why.

​
Find your session ID

There are two kinds, and support can work with either:
  • Meeting session ID: one meeting. A room can host many meeting sessions over time, so the room name alone isn’t enough.
  • Participant session ID: one participant in one meeting. This is the most precise pointer, since it says exactly whose experience to look at.
Where to find them:
  • Dashboard: the Sessions page lists every session on your domain with its session ID, room name, and time. Click into a session to see each participant. The dashboard overview has screenshots.
  • In your app: meetingSessionSummary() returns the meeting session ID. participants() keys each remote participant by session_id. Log these at join time so every user report can be tied to a session later.
  • REST API: the /logs endpoint accepts session IDs for post-call lookups.
Share the full session ID. A shortened one can’t be pasted into a lookup, so support has to ask for it again.

​
The checklist

Collect as much of this as you can:
  1. Session ID and domain. Required. The full meeting session ID, the participant session ID of the affected user if you have it, and your Daily domain name. Without these, support has to ask before doing anything else.
  2. Time window, with timezone. When the problem started and roughly how long it lasted, so support can jump to the right spot in the logs.
  3. What happened, in the user’s own words. “Couldn’t hear the other person for the last 10 minutes” and “audio was choppy the whole call” point at different causes. Keep the original wording.
  4. Environment. Browser and version, OS and version, and which SDK you use and its version (daily-js, daily-python, Prebuilt, or a mobile SDK). Some bugs only show up on one browser or one SDK version.
  5. Network context. Corporate network or VPN? Which country? Wifi or wired? Firewalls and VPNs are a common cause of connection failures, and the logs can’t show this.
  6. Reproduction steps. If you can make it happen again, the exact steps. If it happened once, what the user was doing at the time.
  7. Browser console output. The full console from the affected user’s browser, captured while the problem was happening. Red errors matter most, but the surrounding messages help too. If you can reproduce the issue, turn on debug logging first (see below).
  8. A screen recording with a visible timestamp. For visual problems (a frozen tile, a black screen, an error dialog), a recording that shows a wall clock lets support line it up with the session’s event log to the second.
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'). For recording or transcription issues, add: the recording or transcript ID, the room name, how the recording was started (client method, REST API, or token auto-start), and any recording.error or transcript.error webhook payloads you received.

​
Check what you can see yourself first

Two quick checks resolve many tickets:
  • The status page: if many calls are failing at once, check for a known incident first.
  • The dashboard session: the Sessions page gives you the same per-participant logs and charts support starts from. The debugging call issues guide shows what to look for.

​
What Daily can and cannot see

  • Daily does not record audio or video unless you enable recording. Investigations use metadata: logs, connection events, and quality metrics.
  • A user who never connected leaves little trace. If the failure happened before reaching Daily’s servers (a firewall block, a bad URL, a crash on page load), there may be no session at all. The browser console is the only evidence, which is why the checklist asks for it.
  • Short sessions have little data. Metrics are collected once a second participant joins, but the first sample is logged after 15 seconds (then every 15 seconds). A session that lasted a few seconds may have logs but few or no metrics.
  • Phone and SIP participants report less. A PSTN caller’s phone doesn’t run Daily’s client, so there are no client-side metrics for that leg.
With a session ID, a time window, and one piece of captured evidence, most investigations start right away. Reach support at help@daily.co.