Monitoring for voice, video and voice AI

Your uptime check says 200 OK.
The call still has no audio.

RTCanary places real test calls into your voice and video stack on a schedule, scores the media and the conversation, and alerts you when something drops, before users do. WebRTC rooms, TURN servers, SIP trunks, voice-AI agents and realtime APIs.

Start free Request a demo

No SDK in your client · Probes in five regions · Runs on every deploy · MCP server for your on-call agent

support-change-email · us-eastevery 5 min

dial

1.4 s

turn 1

0.9 s

turn 2

1.1 s

barge-in

410 ms

turn 3

2.9 s

media mos

4.2

agent_pipeline · time_to_first_token
ttft 2.9 s against a 0.8 s baseline, first seen on release 4f2c91a. Media RTT 41 ms, loss 0 %.

failing · turn 3 of 3sample run

Runs againstLiveKitDailyTwilioJitsimediasoupcoturnSIP trunksPipecatVapiRetellOpenAI RealtimeGemini LiveEleven RealtimeNova Sonic

What a canary call catches that an HTTP check cannot

Signalling servers answer 200 while media silently fails. The failure modes below are invisible to uptime monitors and to server-side dashboards, because nothing on the server side is broken.

01 · ICE

TURN stops allocating

Expired TLS certificate on turns:, exhausted quota or a blocked UDP port. Users behind corporate NAT cannot connect; everyone else is fine, so the dashboard looks green. How to monitor a TURN server.

02 · Media

One-way or no audio

Peer connection reaches connected, RTP never arrives in one direction. SIP-side: an ALG rewrote the SDP. Only an endpoint that listens for audio can see it.

03 · Quality

Jitter and loss creep up

A route change or an overloaded SFU raises jitter from 8 to 40 ms. No errors, no alerts, MOS drops from 4.2 to 3.3 and support tickets follow a day later.

04 · Voice AI

Agent answers late, or off script

Time-to-first-audio doubles after a model or prompt change, or the agent stops following the flow it passed in CI. Transcripts look fine; callers hang up during the silence. Monitoring for voice agents.

05 · Regions

One region degrades

Media works from your office and breaks from São Paulo. Probes in several regions make the difference visible instead of anecdotal.

06 · Deploys

A release or a model swap breaks the call

A client build ships with a changed ICE config, or the agent moves to a new speech-to-speech model overnight. A canary triggered by the deploy flags it against the previous release within the first minute.

How a check runs

Each check is a scripted call from a probe you choose, repeated on a schedule. The probe measures what a real participant would experience and compares it with your thresholds.

Step 1 · Join

A headless browser, SIP endpoint or phone leg joins through your real join flow: URL plus token, an INVITE to your trunk, or a dialled number. Nothing is installed in your client.

Step 2 · Exchange media

The probe publishes a reference audio and video stream and listens for yours. It records ICE candidate pairs, the selected transport and the time to first decoded frame.

Step 3 · Measure

Round-trip time, jitter, packet loss, bitrate and frame rate from getStats() or RTCP, an E-model MOS estimate for the audio leg, and the scenario result for an agent.

Step 4 · Alert

Thresholds per metric and per region, with a minimum number of consecutive failures before an alert. Slack, webhook or PagerDuty, with the full trace and the root-cause attribution attached.

Full description of what is measured

Six kinds of check

Each targets one layer of a real-time stack. Combine them to localise a failure: if the TURN probe passes and the room join fails, the problem is not the relay.

WebRTC room

Join, publish, subscribe

Works with any platform that exposes a join URL or token: LiveKit, Daily, Twilio Video, Jitsi, Janus, mediasoup, or your own SFU.

TURN / STUN

Binding and allocation

STUN binding, TURN allocation over UDP, TCP and TLS, relay round-trip and certificate expiry, from several regions.

SIP trunk

OPTIONS and test call

Registration, OPTIONS ping, a short INVITE with reference audio, RTCP-derived loss, jitter and MOS. Post-dial delay as a metric.

Voice-AI agent

Scripted conversation

Calls the agent over the phone, WebRTC or your realtime endpoint, runs a multi-turn script, checks each reply, measures time-to-first-audio, turn latency and whether the agent stops when interrupted.

Realtime API

Session and first audio

Opens a WebRTC or WebSocket session to a speech-to-speech model endpoint (gpt-realtime, Gemini Live, Eleven Realtime, Nova Sonic) or your own gateway, streams audio in, and times session setup, first audio delta and turn completion.

Private probe

Inside your network

A container you run in your VPC or office network, for SFUs, PBXs and TURN servers that are not reachable from the internet. Same checks, same alerts, your egress.

Built for voice AI, readable by agents

A voice agent fails in ways a ping never sees: it answers a second late, talks over the caller, or quietly stops following its flow. RTCanary treats the conversation as the thing under test, and the on-call engineer reading the result may be an agent too.

Evals in production

Scenarios, not pings

A scenario is a scripted dialogue. The canary speaks each turn, records the reply and checks it: a keyword, a DTMF tone, a transfer, an intent judged against a rubric you write. Scenarios run on a schedule against the live agent, so a prompt or model change that breaks a flow is caught between releases, not only before them.

Attribution

Root cause in the alert

Every alert carries an attribution: the network leg (RTT, loss, jitter on the media path), the transport (ICE and TURN, SIP, carrier), or the agent pipeline (end of utterance, time to first token, synthesis). Structured JSON that a person can read at 3 a.m. and an agent can act on.

MCP server

Your agents can ask

Connect RTCanary to Claude Code, Cursor or your own on-call agent through the Model Context Protocol: list checks, fetch the failing run with its trace, ask why it failed, mute a check during a deploy. The same data is a REST API and exports to Prometheus and OpenTelemetry. API and MCP reference.

Model swaps

Compare before you switch

Point the same scenario at the current model and at a candidate, from the same regions at the same minute. The run diff shows time to first audio, barge-in handling and scenario verdicts side by side, so the decision to move to a new realtime model rests on your flows, not on a leaderboard.

Releases

Runs on every deploy

One API call from CI runs the critical checks right after a deploy and tags the runs with the release. A regression is reported against the release that introduced it, and the job can fail before traffic shifts.

Callers

Not every caller is in a quiet room

The canary speaks with caller profiles: clean speech, street noise, speakerphone, a second voice in the background. For outbound agents it answers the call instead of placing it, and reports what the callee experiences: the caller ID shown, the delay before the first word, how voicemail is handled.

CI · after deployREST

# run the critical flows once, fail the job if they fail
curl -sS --fail-with-body -X POST https://api.rtcanary.com/v1/runs \
  -H "Authorization: Bearer $RTCANARY_TOKEN" \
  -d '{"checks": ["support-change-email", "prod-room-join"],
       "release": "4f2c91a", "wait": true}'

→ 2 checks · 4 regions · 38 s
prod-room-join        pass
support-change-email  fail  turn 3 · agent_pipeline

On-call agentMCP

> why is support-change-email failing in us-east?

rtcanary.get_run · rtcanary.compare_runs

Turn 3 has failed on every run since release 4f2c91a. Time to first token is 2.9 s against a 0.8 s baseline. Media RTT is 41 ms with no loss, and the carrier leg is unchanged, so the delay is inside the agent pipeline. The last passing run was on release 9be03d7.

Free tool

MOS calculator

Estimate the R-factor and MOS of a call from one-way delay, packet loss and codec with the ITU-T G.107 E-model. The same model the product uses for its audio score.

Open the calculator

Guides

Written from the standards, not from marketing pages

WebRTC testing, MOS, TURN monitoring, VoIP metrics and voice-agent latency, with every number linked to the RFC, ITU-T recommendation or vendor document it comes from.

Read the guides

Get started

First checks running within one working day

Start on the free tier: three checks, one region, no card. Send the join URL, TURN URI, trunk or phone number you want watched and an engineer sets up the first canaries with you.

Tell us about your stack

Which platform you run (LiveKit, Twilio, Jitsi, a SIP trunk, a voice agent on Pipecat, Vapi or a realtime model API), where your users are, and what failed last time.