Where the probe runs
Checks run from probe locations you select: Frankfurt (eu-west), Virginia (us-east), Oregon (us-west), Singapore (ap-southeast) and São Paulo (sa-east). A private probe, a container you run inside your own network, covers SFUs, PBXs and TURN servers that are not reachable from the internet. A WebRTC check is executed by a headless Chromium instance with fake media devices; a SIP check by a software endpoint that speaks SIP over UDP, TCP or TLS; a TURN check by a small client that performs the STUN and TURN message exchange directly.
The probe does not need anything installed in your client application. It uses the same join mechanism a user would: a room URL with a token, a meeting link, SIP credentials, or a phone number for a voice agent.
WebRTC room check
The probe opens your join URL, authenticates with the token you provide, publishes a reference audio track (a speech sample) and a video track (a timestamped test pattern), and subscribes to whatever the room sends back. Many teams point the canary at a dedicated test room with a second, static participant so that both directions of media are exercised.
Collected every second from RTCPeerConnection.getStats() (W3C WebRTC Statistics API) and summarised per check:
| Metric | Source | Why it matters |
|---|---|---|
| Time to connected | ICE and peer connection state transitions | Join latency as the user experiences it; a jump often means TURN fallback |
| Selected candidate pair | candidate-pair, local-candidate, remote-candidate | Host, server-reflexive or relay; protocol UDP, TCP or TLS. Shows whether TURN was needed and whether it worked |
| Time to first decoded frame / audio sample | inbound-rtp frames decoded, audio samples received | Detects “connected but silent” sessions |
| Round-trip time | candidate-pair.currentRoundTripTime, RTCP | Network distance to the SFU or peer |
| Jitter, packet loss | inbound-rtp.jitter, packetsLost | Primary inputs of the audio quality estimate |
| Bitrate, frame rate, resolution | inbound-rtp, outbound-rtp | Bandwidth estimation and simulcast layer behaviour |
| Concealment events | inbound-rtp.concealedSamples, concealmentEvents | Audio the decoder had to invent; closer to what the listener hears than raw loss |
| MOS estimate (audio) | ITU-T G.107 E-model from delay, loss and codec | One number for alert thresholds; see the calculator for the model |
TURN and STUN check
The probe sends a STUN Binding request (RFC 8489) and, for TURN, an Allocate request (RFC 8656) with the credentials you configure, including time-limited credentials generated from a shared secret. It then relays a small packet through the allocation and measures the round trip. The check runs separately over UDP, TCP and TLS, so a blocked UDP port or an expired certificate on the TLS listener shows up as a failure of one transport rather than a vague “connection issue”.
Reported: allocation success per transport, allocation latency, relay round-trip, the relayed address family, days until certificate expiry, and the error code returned by the server when allocation fails (for example 401, 438 or 486). The failure modes behind these codes are covered in the guide on monitoring a TURN server.
SIP trunk check
Two modes. A lightweight mode sends an OPTIONS request and measures the response time and status code. A full mode registers if required, sends an INVITE to a number you designate (typically an echo test or an IVR that plays a known prompt), exchanges RTP for a configurable duration, and reads loss, jitter and round-trip from RTCP reports (RFC 3550) and RTCP XR when the far end sends it (RFC 3611). Post-dial delay, the time from INVITE to the first 180 or 183 response, is reported as its own metric because it is what callers perceive as “the phone is not ringing”.
Voice-AI agent check
The probe calls the agent through the same channel your users use: a WebRTC session (for example a LiveKit or Pipecat room) or a phone number. It plays a scripted utterance, waits for the agent's reply and records the time from the end of the utterance to the first audio sample from the agent (time-to-first-audio). Optionally it interrupts the agent mid-sentence and measures how long the agent keeps talking. Network metrics for the media leg are collected as in the WebRTC check, so a slow reply can be attributed to the network or to the agent pipeline. How that attribution works is described in measuring voice-AI agent latency.
A scenario can have several turns, each with an expectation: the reply contains a phrase, matches a pattern, plays a DTMF tone, offers a transfer, or satisfies a rubric evaluated by a judge whose verdict is stored with the run. A failed expectation is reported separately from a latency failure. The product page on monitoring for voice agents describes the scenarios in detail.
Realtime API check
The probe opens a session to a realtime endpoint, either an OpenAI Realtime-style API over WebRTC or WebSocket or your own gateway in front of it, sends a short audio prompt and records session setup time, time to the first audio delta, time to the end of the response and the media statistics of the leg. It separates a slow upstream model from a slow network the same way the agent check does, and it is the check to use when the agent platform is yours but the model endpoint is not.
Thresholds, schedules and alerts
Each check has a schedule (from every 30 seconds to once an hour), a set of thresholds per metric with warn and fail levels, and a rule for how many consecutive failures from how many regions are required before an alert fires. The default is two consecutive failures from two regions, which filters out single-probe network blips. Alerts go to Slack, a webhook or PagerDuty and include the full per-second trace of the failing run, the selected candidate pair and the server error codes, so the person on call can see whether TURN, signalling or media failed without reproducing the call.
What a canary does not see
- Problems on a specific user's device or network. A canary measures from the probe's location with a known-good device. It tells you the service is healthy from there; it cannot tell you why one customer on hotel Wi-Fi has bad audio. Client-side telemetry (RUM) covers that, and the two are complementary.
- Regions without a probe. If your users are in Jakarta and the nearest probe is in Frankfurt, the check reflects Frankfurt. Add a probe region or a private probe; regions per tier are listed on the pricing page.
- Perceived quality beyond the model. The MOS estimate is an E-model computation from network metrics and codec, not a listening test. It ranks degradations well and tracks changes over time; it does not reproduce a human rating of a particular recording.
- Load. A canary is one participant. It will not reveal that your SFU falls over at 400 participants; load testing tools exist for that; see the guide on WebRTC testing for which tool covers which layer.
A wider comparison of uptime checks, HTTP synthetics, RUM and call canaries is in the guide on synthetic monitoring for voice and video.