The replay is only half the story. Backstory records WebRTC state and quality next to the page, so a frozen video and the click that followed it sit on one timeline.
WebRTC quality events sit on the same timeline as everything else, so the moment a call degraded is the moment you can scrub to.
Every replay tool can show you a user clicking. None of them can tell you the far end never sent audio.
Packets leave one side and never arrive at the other, while both ends believe the call is up. We see outbound packets climbing against a receiver that reports nothing, and name it. Today this is a twenty-minute phone call that ends in a shrug.
Another application is holding the camera, so the browser rejects the request with NotReadableError. The user sees a black rectangle and blames your app. We record the exact rejection class before any video was ever negotiated.
The network blocked peer-to-peer, so media went through a TURN relay and picked up latency on the way. The candidate types prove it. One relayed call is normal; relayed calls concentrated in one site or one release is a finding.
The encoder could not keep up, so it dropped resolution. Not the network: the device. On a shared workstation or a wall-mounted kiosk this is the usual answer, and it points at hardware rather than bandwidth.
We record metrics and state. The call's audio and video never leave the device, in any configuration. That is what makes call observability safe to switch on in a HIPAA environment, where the media itself is protected health information. ICE candidate addresses are hashed, device labels are masked, and session descriptions are off by default.
The SDK wraps the browser APIs your call already uses. Nothing to instrument, no SDK of ours inside your call logic. Apps that build a peer connection before we load get an attach() escape hatch.
A quality sample is a few hundred bytes, so a call costs a handful of kilobytes per minute. Next to the DOM stream it does not register.
The same metric shape and the same detectors on the browser, iOS, and Android. Vendor SDKs that hide the peer connection can hand us their own statistics instead.
The SDK differences getStats() reports on the device and sends conclusions. What arrives is already the number you would have computed.
| Metric | Derived from | What it proves |
|---|---|---|
| Packet loss | packetsLost against packets received, or the remote report for outbound | The strongest single predictor of a call people complain about |
| Round trip time | currentRoundTripTime on the selected candidate pair | Conversational latency. Past 300 ms, people start talking over each other |
| Jitter and buffer delay | jitter, and jitterBufferDelay over its emitted count | Network instability, and the buffering half of perceived lag |
| Freezes | freezeCount and totalFreezesDuration, with a derived fallback where the browser lacks them | The video freezing: what a user means by “choppy” |
| Audio concealment | concealedSamples over totalSamplesReceived | Dropouts. The decoder inventing samples to cover gaps. Past roughly 5% it is audible |
| Frame rate and resolution | framesPerSecond, frameWidth, frameHeight | Quality collapse under bandwidth or CPU pressure |
| Quality limitation reason | qualityLimitationReason and its durations | Whether the network or the device was the constraint |
| Available bitrate | The congestion controller's own estimate | How much headroom was left before it degraded |
| Candidate types | The selected pair joined to the candidate stats | Direct or relayed, over UDP or TCP, on wifi or cellular |
| Audio level | The receiver level, or the local media source | Silence while unmuted: half of the one-way audio diagnosis |
Deterministic, tunable per project, and clustered across sessions the same way every other Signal is.
| Detector | Rule (defaults) | Severity |
|---|---|---|
| Connect failure | Never reached connected within 15 s, or reached failed | Critical |
| One-way media | One direction moved zero packets for 6 s while the other flowed | Critical |
| Media permission denied | getUserMedia rejected with NotAllowedError | High |
| Device unavailable | Rejected with NotReadableError or NotFoundError | High |
| Freeze | A single freeze over 2 s, or more than 5% of the call frozen | High |
| Audio dropout | Concealment above 5% sustained for 10 s | High |
| Reconnect storm | Three or more ICE restarts or path changes within 60 s | High |
| Call abandoned | Ended inside 30 s with a quality score below 60 | High |
| Packet loss | Above 5% sustained for 10 s | Medium |
| High latency | Round trip time above 300 ms sustained for 15 s | Medium |
| CPU limited | Encoder CPU-limited for more than 20% of the call | Medium |
| Low resolution | Below 240 px high for 20 s after a better resolution was seen | Low |
| Relay fallback | The selected path is a TURN relay | Info |
Each call also gets a composite quality score from 0 to 100, weighted toward loss and freezes. The score the detector fires on and the score a support agent reads are computed by the same function, so they cannot disagree.
A dedicated WebRTC dashboard will tell you the jitter buffer reached 400 ms. It cannot tell you the user clicked Start, waited eight seconds, saw nothing, clicked Refresh three times, and got a 500 back from your session endpoint. A replay tool can show you all of that and has no idea the media path had failed over to a relay.
Putting both on one timeline is the point. The Media panel sits beside Console and Network in the Player, with metric lanes aligned to the scrubber and a marker for every state change. Because no frames were recorded, a frozen video element is labelled with the freeze and its duration, which is the more useful artifact anyway. Ask Why weighs the call and the page together, so the explanation names both halves of the failure and cites the moment of each.
Per connection: state at the playhead, direct or relayed, codec, and the running score. Lanes for latency, loss, jitter, frame rate, bitrate, and audio level. Freeze bands. Clickable markers.
Every call, with quality score, setup time, relay status, network type, and the issues found. Filter to the bad ones, then jump into the replay at the moment it went wrong.
Connect failure rate and relay rate broken down by network type, browser, device, and release. The question “is it us or their network” becomes answerable.
A WebRTC call can run for a full shift. Recording all of it would be expensive and almost entirely uninteresting. Every call detector doubles as a monitor-mode trigger, so a lost feed, a freeze, or a reconnect flushes the sixty-second pre-roll and records a full-fidelity burst around the problem.
What a supervisor reviews the next morning is a handful of bursts with the minute before each one intact, not twelve hours of a stable video wall. See kiosks and monitoring for how monitor mode works.
Client statistics describe one participant's experience. Joining them to the media server's view separates a bad uplink from a bad downlink. Where a customer runs their own media server, the participant identity is the join key and the two land on the same call record; the same pattern applies to any hosted service that reports per-participant statistics. Call quality is also exported as OpenTelemetry metrics, so an existing observability stack can consume it without integrating with us at all.
Free for 1,000 sessions a month. Strict masking, conditional recording, and Signals are all included.
Free for 1,000 sessions a month, no credit card. Or leave a work email and we will reach out about the private beta for healthcare and support teams.
We'll reach out to about the private beta.
We'll email when Backstory opens.
