When is building it yourself the right call?

That's up to you, but frankly? If you want to take this route, better start with our open source project so you hit the ground running. Nothing ties you in to use any of our commercial offering by doing that.

What does building it actually involve?

Four pieces. Instrument the client to poll getStats() on an interval across every peer connection. Ship those samples somewhere without adding meaningful bandwidth or CPU to a real-time session. Store time series per session and per participant in something that can answer questions across a whole conference. Then put a dashboard on top. Did I mention you can take most of it 'as is' by just using our open source components?

What does it cost to maintain afterwards?

Three costs land after the prototype works. getStats() is a moving specification and browsers change what they emit, so the fields you parse today will drift and keeping up is permanent. Storage grows faster than planned once you keep raw per-second samples, and sampling less quietly costs you the ability to debug the rare bad call that prompted the project. And turning charts into a verdict about the call is a separate piece of work from collecting the data.

Is rtcstats-js really open source?

Yes. The collection layer lives in the monorepo at github.com/rtcstats/rtcstats. You can run rtcstats-js in your client and rtcstats-server in your own infrastructure, keep the raw data, and forward nothing at all. Forwarding to the hosted analysis is off by default and what you send is configurable.

Can I build on it and add the hosted analysis later?

Yes, and that is the usual path. The two halves separate cleanly, so a team can run the collector for months, decide the interpretation is taking too long to build, and start forwarding a slice without changing what they already deployed. Nothing about the collection side has to be unwound.

Can I add my own data to a session?

Yes. Sessions can be enriched with your own application context, which is the thing a purely external tool cannot do for you. This is often the strongest argument for the build path, and it is also available without abandoning the hosted analysis.

Do I have to deploy anything to try the analysis?

No. Upload an existing dump by hand and get the full analysis back with nothing deployed. It is the cheapest way to find out whether the interpretation layer is worth the part of the project you were about to start.

rtcStats vs building it yourself

Building your own means writing the collection layer, the storage and the dashboards, then maintaining them as browsers change. Our collection layer is open source, so you do not have to start from scratch. Here is what the rest of it costs.

Get started free Check our showcase

Why choose rtcStats?

You are not starting from nothing either way

rtcstats-js and rtcstats-server are open source, so the collection half is available to you whether or not you ever pay us. Building on them is a supported path rather than a workaround.

The hard half is already written

Turning thousands of metrics into a statement about what a person experienced is the expensive part. Observations, Deductions and the Experience Score are that work, already done.

Browsers keep moving

getStats() is a live specification and the fields you parse correctly today will drift. That maintenance is permanent, and it is the cost most build estimates leave out entirely.

At a glance

	Building it yourself	rtcStats
Collection layer	No, you write one	Yes, rtcstats-js
Ingestion, storage and aggregation	No, you build it	Yes, rtcstats-server
Dashboards and visualization	No, you build them	Yes
Automated fault detection	No	100+ issues flagged as Observations
AI summary of what went wrong	No	Yes
API and MCP server	No, you build them	Yes, both
Maintained as browsers change getStats()	No, that is yours permanently	Yes
Commercial support	No	Yes, hosted or fully on-premise
Time before the first useful answer	Weeks of engineering	Minutes, upload a dump
Runs in your own infrastructure	Yes	Yes
You own the raw data	Yes	Yes

Collection layer

Building it yourselfNo, you write onertcStatsYes, rtcstats-js

Ingestion, storage and aggregation

Building it yourselfNo, you build itrtcStatsYes, rtcstats-server

Dashboards and visualization

Building it yourselfNo, you build themrtcStatsYes

Automated fault detection

Building it yourselfNortcStats100+ issues flagged as Observations

AI summary of what went wrong

Building it yourselfNortcStatsYes

API and MCP server

Building it yourselfNo, you build themrtcStatsYes, both

Maintained as browsers change getStats()

Building it yourselfNo, that is yours permanentlyrtcStatsYes

Commercial support

Building it yourselfNortcStatsYes, hosted or fully on-premise

Time before the first useful answer

Building it yourselfWeeks of engineeringrtcStatsMinutes, upload a dump

Runs in your own infrastructure

Building it yourselfYesrtcStatsYes

You own the raw data

Building it yourselfYesrtcStatsYes

What rtcStats gives you that you would otherwise build

The collection layer is free

Not a trial and not a reduced tier. rtcstats-js and rtcstats-server are the same code we run ourselves, and running only that half is a supported way to use rtcStats. If you were going to build a collector anyway, starting here saves the part of the project nobody enjoys and none of the part that differentiates your product.

The analysis is the part worth buying

"We have dashboards" turns into "which of these forty charts means the call was bad", which is a different project from the one you just finished. That pattern recognition comes from a large number of real broken calls across many networks and devices, and it is what rtcStats sells. We would rather say that plainly than imply the collector is where the value sits.

The middle path most teams reach

Self-host the collection, send a selected slice for analysis. You own the raw data outright and buy the answer for the sessions where an answer is worth paying for. If the balance shifts later, in either direction, the collection layer you are already running does not have to change. Scaling notes cover the half you operate.

Frequently asked questions

That's up to you, but frankly? If you want to take this route, better start with our open source project so you hit the ground running. Nothing ties you in to use any of our commercial offering by doing that.
Four pieces. Instrument the client to poll getStats() on an interval across every peer connection. Ship those samples somewhere without adding meaningful bandwidth or CPU to a real-time session. Store time series per session and per participant in something that can answer questions across a whole conference. Then put a dashboard on top. Did I mention you can take most of it 'as is' by just using our open source components?
Three costs land after the prototype works. getStats() is a moving specification and browsers change what they emit, so the fields you parse today will drift and keeping up is permanent. Storage grows faster than planned once you keep raw per-second samples, and sampling less quietly costs you the ability to debug the rare bad call that prompted the project. And turning charts into a verdict about the call is a separate piece of work from collecting the data.
Yes. The collection layer lives in the monorepo at github.com/rtcstats/rtcstats. You can run rtcstats-js in your client and rtcstats-server in your own infrastructure, keep the raw data, and forward nothing at all. Forwarding to the hosted analysis is off by default and what you send is configurable.
Yes, and that is the usual path. The two halves separate cleanly, so a team can run the collector for months, decide the interpretation is taking too long to build, and start forwarding a slice without changing what they already deployed. Nothing about the collection side has to be unwound.
Yes. Sessions can be enriched with your own application context, which is the thing a purely external tool cannot do for you. This is often the strongest argument for the build path, and it is also available without abandoning the hosted analysis.
No. Upload an existing dump by hand and get the full analysis back with nothing deployed. It is the cheapest way to find out whether the interpretation layer is worth the part of the project you were about to start.

This comparison is based on an analysis of publicly available information researched in August 2026. Products change. If something here is out of date, tell us and we will correct it.

Try it on a real session

Free plan, no credit card. Upload a dump and see what the analysis says about a call that went wrong.

Get started free