Monitoring LiveKit with Vigilmon

LiveKit is the leading open-source WebRTC SFU (Selective Forwarding Unit) for real-time audio/video infrastructure — from voice AI agents to video conferencing products serving thousands of concurrent rooms. That central position means a LiveKit failure instantly interrupts every active session. Vigilmon gives you external visibility into LiveKit's health endpoint, signaling port, TURN/STUN connectivity, and SSL certificate status so you catch failures before users do.

What You'll Set Up

• HTTP health check on the LiveKit server health endpoint
• TCP port monitor for the WebSocket signaling port (7880)
• TCP port monitor for TURN/STUN (3478)
• SSL certificate expiry alerts for HTTPS/WSS endpoints
• Heartbeat monitor for LiveKit room service availability

Prerequisites

• LiveKit server running (Docker, binary, or Kubernetes)
• LiveKit accessible on a public hostname or IP
• A free Vigilmon account

Step 1: Monitor the LiveKit Health Endpoint

LiveKit exposes an HTTP health route at /rtc/validate (or a plain HTTP health path depending on your version and configuration). This endpoint returns 200 OK when the SFU is ready to accept connections.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: https://livekit.yourdomain.com/rtc/validate
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

If you're running LiveKit without a custom domain behind a load balancer, use the direct IP and port:

http://YOUR_SERVER_IP:7880/rtc/validate

This catches the SFU process crashing, a failed config reload, or the server being unreachable after a host restart.

Step 2: Monitor the WebSocket Signaling Port (7880)

LiveKit's primary signaling channel runs over WebSocket on TCP port 7880. Clients connect here to establish room sessions. If this port is unreachable, no new sessions can be created regardless of what the HTTP health check returns.

Add a TCP port monitor:

1. Click Add Monitor → TCP Port.
2. Host: livekit.yourdomain.com, Port: 7880.
3. Set Check interval to 1 minute.
4. Click Save.

A TCP failure on port 7880 means either the LiveKit process has crashed, the port binding has been lost, or a firewall rule is blocking client connections.

Step 3: Monitor the TURN/STUN Port (3478)

LiveKit includes a built-in TURN/STUN server for clients that can't establish direct peer connections (e.g. corporate networks behind strict firewalls). The TURN server listens on TCP and UDP port 3478.

Add TCP monitoring for the TURN port:

1. Click Add Monitor → TCP Port.
2. Host: livekit.yourdomain.com, Port: 3478.
3. Set Check interval to 2 minutes.
4. Click Save.

If you're using an external TURN server (Coturn, Cloudflare TURN), point the monitor at that host instead. A dead TURN server silently degrades call quality for clients on restricted networks — they may connect briefly, then drop or experience one-way audio.

Step 4: SSL Certificate Expiry Alerts

LiveKit's WebSocket signaling endpoint (wss://) and HTTPS health route both depend on a valid TLS certificate. A lapsed certificate causes all WebRTC clients to fail the TLS handshake, instantly disconnecting every active room.

Enable SSL monitoring on the HTTP monitor you created in Step 1:

1. Open the LiveKit health endpoint monitor.
2. Scroll to the SSL certificate section.
3. Enable Monitor SSL certificate.
4. Set Alert when certificate expires in less than 21 days.
5. Click Save.

A 21-day window gives you time to investigate cert renewal failures and manually rotate if your automated tooling (cert-manager, Let's Encrypt) has silently stopped working.

Step 5: Heartbeat Monitoring for Room Service Availability

LiveKit's HTTP health endpoint confirms the process is running, but it doesn't verify that the Room Service API is actually creating and managing rooms. Use a heartbeat monitor combined with a lightweight ping from a LiveKit SDK client or livekit-cli to verify end-to-end room service health.

In Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 5 minutes.
3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Then configure a scheduled script that exercises LiveKit's Room Service API and pings the heartbeat on success:

#!/bin/bash
# Run every 5 minutes via cron or a systemd timer

# Create a test room, verify the API responds, then delete it
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://livekit.yourdomain.com/twirp/livekit.RoomService/ListRooms \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}')

if [ "$RESPONSE" = "200" ]; then
  curl -s https://vigilmon.online/heartbeat/abc123
fi

If the Room Service API stops responding — even while the health endpoint returns 200 — the heartbeat goes silent and Vigilmon alerts after 5 minutes.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add your preferred channel (Slack, email, or webhook).
2. Set Consecutive failures before alert to 2 on the signaling port monitor — LiveKit restarts take a few seconds and a single probe failure during restart is normal.
3. Group all LiveKit monitors under a named service group so a full outage generates one grouped alert instead of individual notifications for each monitor.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Health endpoint | https://livekit.yourdomain.com/rtc/validate | SFU crash, config failure | | TCP signaling | :7880 | Process down, port binding lost | | TCP TURN/STUN | :3478 | TURN server failure | | SSL certificate | WSS/HTTPS domain | Cert expiry, renewal failure | | Cron heartbeat | Room Service API | Room service degradation |

LiveKit's low latency and high concurrency make it an invisible but critical piece of real-time infrastructure. With Vigilmon monitoring the signaling port, health endpoint, TURN connectivity, and SSL certificates, you'll know about failures in seconds rather than when users start complaining about dropped calls.