Stop guessing why WebRTC calls fail
Drop in our open-source SDK or upload a webrtc-internals file. We turn your raw data into answers.
Your first month runs at full Developer-level analysis. No credit card.
Built by WebRTC OGs with 20+ years in the trenches.
See real analyses of LiveKit, NVIDIA, and Netflix →
“I Googled, came across your offering - being able to download it, start it up without a credit card, run a couple of calls through it and go: yes, if this works across my user calls, it's absolutely worth the asking price.”
Brett BenderHead of Engineering, Bond
“The rtcStats dashboard gives our team an immediate, visual read of each WebRTC session: [...] an engineer can spot the problem in minutes rather than hours. [...] [T]he rtcStats dashboard is where the diagnosis starts. It has turned voice quality from guesswork into evidence.”
Girish DharmarajCTO, Toku
Your users notice a bad call before your monitoring does
Your server logs only see a slice of the problem. rtcStats collects from the client, where WebRTC calls actually break.
Collect
Gather WebRTC stats via SDK or file upload
Review
What went wrong on the call, and who owns the fix
Resolve
Zero in on the issue and fix it fast
From WebRTC stats to actionable answers
Quality
Did the participants hear and see each other well?
Who reads it: Support, and the end user they are helping.
- Sustained packet loss on incoming media
- High freeze duration
- Strong echo at the microphone
You see whether the problem sits with the user's network and devices or with how your app sends media and handles echo.
Performance
How fast was it?
Who reads it: Engineering, for latency and setup-time work.
- Long connection setup
- High TURN delay
- High encode time
You find the slow step, from signaling to encoding, and fix that step instead of the whole stack.
Reliability
Did the call work at all, did it stay up, and did it recover?
Who reads it: Support, operations, and whoever runs your TURN and signaling servers.
- Connection failed to establish
- ICE connection failed
- TURN Authentication Error
You see where the connection broke, and whether the fix is in your TURN servers or in how your app handles ICE.
Best practice & Code
Does the code use WebRTC correctly?
Who reads it: Your application developers.
- No specific audio and video constraints
- SDP content changed
- Too many getUserMedia requests
You fix it in code before the next user hits the same bug.
From raw metrics to root causesin five layers
Deductions
Deducing root causes and suggesting solutions
Observations
Reviewing one or more metrics to find interesting observations
Features
Structured per-session facts written to SQL for cross-session analysis
Calculations
Rates, averages, aggregations and quality estimates like MOS
Foundations
Raw metrics collected via WebRTC APIs directly
You collect the raw metrics with our open-source rtcstats SDK, and we do the heavy lifting to take you from raw numbers to the observations and deductions of what happened.
WebRTC observability isn't your core competency. It's ours.
You should be shipping your product, not building a stats pipeline. Keep your Grafana dashboards. rtcStats adds what they can't do: an experience score, observations and the likely root cause for every session, from a team that has lived inside WebRTC for 15+ years.
Your data stays yours
Open-source collector
rtcstats-js and rtcstats-server are yours to run and keep.
Your storage
The server writes raw stats to your own bucket.
No lock-in
Stop using rtcStats and you keep the collector and every file it gathered.
Your app
rtcstats-js
Your infrastructure
rtcstats-server
collects
Your bucket
raw stats
rtcstats.com
optional
FAQ
Frequently Asked Questions
- Your test network is not your users' network. Real users connect through corporate firewalls, VPNs and NATs, on Bluetooth headsets, and on laptops that run out of CPU. rtcStats reads the client-side data from those real sessions. It tells you what failed, such as ICE connection failed or TURN Authentication Error. It also tells you what the user's setup looked like: UDP blocked, Connected via VPN, A Bluetooth device is being used, High CPU limitation. Collect from production with the open-source rtcstats-js, or upload the rtcstats dump or webrtc-internals file a user sends you.
- The session report tells you. Network trouble shows up under Quality (packet loss, jitter and round-trip time on media that did flow) or under Reliability (a connection that failed or dropped, such as ICE connection failed or a TURN error). Problems your developers fix in code show up under Best practice & Code: getUserMedia without constraints, SDP content changed, Signaling error, and device errors your application should handle.
- Start with the question the Observation answers. Quality goes to support and the end user for a single session, and to your developers when it repeats. Reliability goes to whoever runs your TURN and signaling servers, and to your developers when the fix is in how the app handles ICE. Performance goes to engineering: the slow step in setup or encoding. Best practice & Code goes to your developers as a code change. Each Observation links to a knowledge base article with the details.
- Check Reliability. A connection that failed is a different problem from poor audio or video, and rtcStats reports it on its own. Look for Connection failed to establish, ICE connection failed or TURN Authentication Error in the session report.
- Yes. Sign up and use the free plan as long as you want, with no credit card and no expiration. Your first month runs at full Developer-level analysis. After that, Experience Scores, Observations, Deductions, AI summaries and API access come with a paid plan.
- Paid plans unlock the full analysis pipeline: Experience Scores, Observations, Deductions, root-cause analysis and AI summaries in plain language for every session. You also get more processing credits and API and MCP access. Enterprise plans add the option to embed the rtcStats viewer in your own dashboards.
- Yes. The REST API lets you automate your entire workflow - upload sessions, retrieve observations and deductions, manage quotas, and pull results into your own systems. You own and control your data end to end.
With the rtcstats-enrichment server, the analysis runs inside your network and your session data stays there. With rtcstats-server, only the sessions you choose go to rtcstats.com, and their IP addresses are anonymized before they leave.
rtcStats never collects audio, video, screen content or chat messages. Beyond that, you pick the setup:
- Your infrastructure, your storage. The open-source rtcstats-server runs on your infrastructure and keeps raw data in your own storage, with IP addresses anonymized before anything is shared. You control what gets shared.
- Bring your own storage. Enterprise accounts can use their own object store and database, so raw data never touches our servers.
- On-premise analysis. The rtcstats-enrichment server runs the same engine as rtcstats.com inside your network and returns the Experience Score and Observations as JSON. Contact us about it.
Read more in our Data Privacy and Compliance guide.
Contact us and we'll get back to you.
What's new
What we've shipped
We ship every month. Here's what landed.
rtcStats v2.2 adds an Overview page with the Experience Score of your calls, a redesigned Logs tab, and a major update of the WebRTC knowledge base.
A homegrown getStats() collector gets built once and patched when it breaks. Why that happens, and how to build on maintained open source.
Start using rtcStats
Free plan with 10 sessions per month. No credit card required.
Start analyzing for free