WebRTC monitoring vs observability: what is the difference?

Monitoring tells you what happened on a WebRTC call. Observability tells you why. Here is where the line sits, and which one answers the ticket on your desk.

Last updated 20 Aug 2026Applies toany rtcStats setup

Frequently Asked Questions10 articles

On this page6 sections

The two words get used as synonyms, and in most WebRTC tooling they describe genuinely different things. The short version is that monitoring tells you what happened, and observability tells you why.

A user reports that a call sounded bad. Monitoring hands you the numbers: packet loss hit 6% at 2:14, the MOS dropped to 2.8, the media went through a TURN relay. All of it is true, all of it was measured, and none of it tells you what to do next. Observability is the layer that turns those numbers into a cause. The user's Bluetooth headset renegotiated in the middle of the call. A VPN forced the media onto a path through another continent. Your own encoder gave up resolution because the machine was thermally throttled. Same session, same raw data, a different question answered. The distinction is not academic wording: it decides whether a support ticket closes at the support desk or escalates to an engineer who spends an afternoon scrolling through webrtc-internals.

Why the distinction matters more in WebRTC than elsewhere

In a typical backend service, monitoring and observability sit on data you own. Your servers emit the metrics, your servers emit the traces, and both live in your infrastructure. WebRTC breaks that assumption twice over. The media is encrypted end to end, so no amount of inspection along the path tells you what the user actually experienced, and the SIP-era move of putting a probe in the middle to read the stream simply does not work here. On top of that, a peer-to-peer session may never touch your infrastructure at all. Your servers can be entirely healthy and reporting green while a call between two of your users falls apart on a path you have no visibility into. That is why WebRTC observability has to start at the client: getStats() in the browser is the only vantage point that sees what the user's device, network and browser actually did. Everything else is your servers telling you their own side of the story.

What monitoring gives you

Monitoring is the aggregate, continuous view. It answers questions about volume and trend: how many sessions ran today, what share of them used a TURN relay, how connection setup time is distributed across your user base, whether the p95 got worse after last Thursday's release. This is real value and you want it. It is how you notice a problem exists at all, how you catch a regression that no single user has complained about yet, and how you decide whether the thing in front of you is an outlier or a pattern worth engineering time. If you run rtcstats-server yourself, the feature extraction it performs is exactly this layer: roughly 100 structured values per session, written to SQL, ready to query across every call. What monitoring will not do is close a ticket. Knowing that 6% of your sessions in one country relayed through TURN last week is a fact about your platform, not an answer for the user who called support this morning.

What observability adds

Observability is the per-session, explanatory view. It starts from the same raw metrics and asks what they mean together. Inside rtcStats that progression is explicit, which makes it a useful way to see exactly where the line falls:

Foundations - the raw metrics as getStats() reported them
Calculations - derived values on top of those: rates, averages, MOS
Features - each session compressed into structured facts you can compare across sessions
Observations - rules that flag the moments that mattered, each with a severity
Deductions - what those signals mean together, and the Experience Score that says how the call actually felt

The first three levels are monitoring. They describe what the session did, faithfully and without interpretation, and any team with enough engineering time can build them. The last two levels are observability, and they interpret. That is where the WebRTC expertise lives, because the step from "concealed samples climbed steadily for eleven seconds" to "the jitter buffer was fighting a bad network and the user heard robotic audio" is not something a metric declares about itself. Somebody has to know which combinations of signals mean which real-world failure, and encode it. The gap between the two halves is not data volume. Both halves read the same dump. The gap is judgment about what the numbers add up to.

A worked example

Take a call where the video froze for four seconds. Monitoring reports the freeze accurately: freezeCount incremented, totalFreezesDuration went up, and frames decoded flatlined for the duration. You now know a freeze happened, which is roughly what the user already told you. Observability asks which of several very different stories produced that shape. If packetsLost spiked in the same window and retransmissions did not keep up, the network dropped media and the decoder starved. If packets kept arriving on time but framesDropped climbed while the CPU was pegged, the receiving device could not decode fast enough and the network was fine. If the freeze lines up with an ICE handover, the call moved to a different candidate pair and the gap is the transition itself. Three causes, three completely different fixes, one identical freeze in the monitoring view. Separating them is the entire job.

Which one do you actually need?

Both, and in that order, but the honest answer for most teams is that the observability half is the one they are missing. Almost every WebRTC team already has some monitoring: a homegrown getStats() collector, a dashboard built on their CPaaS vendor's metrics, a rolling window of quality averages. What they do not have is anything that reads one specific bad session and says what went wrong in it, which is why the support ticket escalates and the engineer starts scrolling. rtcStats is built for that second half, and the best practices section describes the three shapes it takes in production: ad-hoc debugging when someone hands you a dump, passive complaint handling when you want every session collected and ready before the complaint arrives, and active observability when you want the client-side data feeding your wider monitoring stack.