Back to Blog

You don't need another dashboard for WebRTC observability

You pull the webrtc-internals dump and scroll thousands of getStats() lines. rtcStats reads it for you, keeps its analysis engine portable, and lets your data stay yours.

Posted by

You don't need another dashboard for WebRTC observability - rtcStats

Running a WebRTC service? You likely get user complaints on media quality every once in awhile: A call that sounded bad. A session that was never connected.

What do you do when that happens? Pull the relevant webrtc-internals file and start scrolling through thousands of getStats() lines looking for the one number that explains it.

Most WebRTC observability tools hand you a nicer version of that same scroll. Prettier charts. More dashboards. Some will even put the metrics on a diet so you don't get lost with all that data. The bottom line? This is still yours to read. Still yours to interpret and figure out. Still at 11pm (or later).

rtcStats is built on three beliefs that most of this market misses:

1. The product is the answer, not the dashboard

A dashboard is a haystack with better lighting. It shows you everything and leaves the reading to you.

rtcStats reads the dump for you. You get Observations (the moments that mattered, and what they did to the call), Deductions (pointing you towards the root causes of issues), an Experience Score (how the call felt, in one number), and an AI Summary (the whole story in plain English). No chart to squint at. No fine print with lots of numbers to decrypt. A clear and crisp answer that is actionable right away.

It does not replace webrtc-internals. It is the layer above it - the pattern-matching a senior WebRTC engineer would do, done for you, in under 30 seconds.

2. The brain is portable

Here's something we've been hard at work at, that most of the market cannot say or do:

Our analysis engine is not welded to our cloud.

We don't store or own the data - you do. Your sessions get collected by you and get analyzed by us at your own decision and discretion.

rtcStats is built as two halves instead - an open-source collection layer you run yourself, and an analysis engine that does not have to live in our cloud. For teams that cannot send session data off their own infrastructure, we can run the same engine on yours - that's the brain piece we've just "cut out" of our own cloud service so that on premise deployments can enjoy the same superpowers without the data-sharing.

The intelligence travels to your data. Your data does not have to travel to us.

3. Your data stays yours

Did I mention that the data is yours?

The collection layer - rtcstats-js and rtcstats-server - is open source and runs inside your infrastructure. You choose which sessions to send for analysis: random sample, per-user, per-region, threshold-triggered, or a single dump when one specific call goes bad. Or nothing at all - if you get that brain of ours run inside your infrastructure as well.

There's no black-box agent in the call path. No vendor lock-in. Send what you want, keep the rest.

Why we built it this way

Most tools in this space start from the dashboard and ask you to trust their cloud. We started from the answer, and we built so your data can stay put. rtcStats is a partnership of three people who have spent their careers in WebRTC - Tsahi Levent-Levi (that's me), Philipp Hancke, and Olivier Anguenot - and this is the product we wanted when we were the ones scrolling getStats() at midnight.

Free plan, no credit card. Upload a webrtc-internals or rtcstats dump and see what rtcStats says about it.

Start at https://rtcstats.com

What is the worst WebRTC call you have ever had to debug, and how long did it take you to find the cause?