Operations

Testing & Verification

We verify each deployment three ways before trusting it — at the protocol, the media, and the user-experience layers.

Packet loss (CLI)

0%

20s, both clouds

Sustained test

45s

0.029% loss

TLS

Valid

Let's Encrypt

1 · CLI load test (media)

Real WebRTC publishers & subscribers

The LiveKit CLI spins up real publishers and subscribers over WebRTC, exercising the SFU end to end and reporting media statistics.

terminal
lk load-test --room smoke \
  --video-publishers 1 --subscribers 1 --duration 20s

# Subscriber summary
#  Tracks  Bitrate    Total Pkt. Loss
#  1/1     1.2mbps    0 (0%)

Both Azure and GCP returned identical, clean results — a track published, forwarded, and subscribed with zero packet loss.

2 · Browser client (experience)

A real client, no code required

We point the hosted meet.livekit.io client at our server (via its Custom tab) using a token minted with lk token create. This confirms camera, mic, and multi-participant rooms work from an actual browser.

3 · TLS & DNS (protocol)

Healthy, encrypted endpoints

terminal
curl https://lk.gcp.involvelxp.com/      # -> "OK" (200)
# WebSocket upgrade probe -> 200
# Certificate issued by Let's Encrypt

A real bug we caught

The browser client initially reconnected every ~15s while the CLI worked fine. The cause: the server was pinned to an older LiveKit version that predated the data tracks feature the modern browser SDK negotiates by default. Upgrading the server to v1.12.0 resolved it. The CLI used a compatible protocol, which is exactly why it never surfaced the issue — a good reminder to test at every layer.