How to measure connection success rate (and why it lies)

Connection success rate is the most-cited and least-defined metric in WebRTC.

A workable definition

A useful definition of a 'successful connection': a session where ICE candidates were exchanged, the PeerConnection reached connected, and at least one bidirectional media frame was confirmed.

Exclude from the denominator: user denials of camera/mic permission, intentional cancels before joining, and outages of the SDK provider's signaling layer (which you can't control).

Why it matters

A 5% drop in success rate is the difference between a feature that 'works' and one users complain about. The complaints are easy to attribute to your code; the actual cause is often the network.

Common failure modes

1. TURN exhaustion — TURN cluster is full. Symptom: relay candidates take 10+ seconds or fail.
2. Restrictive firewall — corporate networks block UDP. Fix: enable TURN/TCP and TURN/TLS, in that order of preference.
3. Browser autoplay policies — calls join muted, user does not realize, thinks the connection failed.
4. Mobile network handoff — wifi → cell mid-call. Modern SDKs reconnect, but only if you handle the events.

Instrumentation

Daily, Agora, and LiveKit all emit connection events. Pipe them to your analytics (a simple Postgres table works fine). Compute the rate weekly. Investigate any week that drops below your baseline.