Monitoring SRS (Simple Realtime Server) with Vigilmon

SRS (Simple Realtime Server) is a high-performance open-source media server used for live streaming infrastructure — supporting RTMP ingest, HLS delivery, WebRTC, and RTSP in a single process. Live streaming is particularly unforgiving of downtime: viewers see a black screen within seconds, and publishers lose their entire audience simultaneously. Vigilmon gives you external monitoring for SRS's HTTP API, RTMP ingest port, HLS delivery endpoints, and WebRTC signaling so you know the moment any stream path fails.

What You'll Set Up

HTTP monitor for the SRS HTTP API health endpoint (/api/v1/versions)
TCP port monitor for RTMP ingest (port 1935)
HTTP monitor for HLS delivery endpoint
TCP port monitor for WebRTC signaling (port 1985)
SSL certificate alerts for HTTPS HLS and WebRTC endpoints
Heartbeat monitor for SRS stream publishing health

Prerequisites

SRS 5+ running (Docker or binary)
SRS HTTP API enabled (http_api in srs.conf)
RTMP ingest and at least one output (HLS or WebRTC) configured
A free Vigilmon account

Step 1: Monitor the SRS HTTP API Health Endpoint

SRS exposes an HTTP API on port 1985 by default. The /api/v1/versions endpoint returns SRS version and build information when the server is healthy — it's the lightest possible liveness check.

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter the URL: http://YOUR_SRS_HOST:1985/api/v1/versions
Set Check interval to 1 minute.
Set Expected HTTP status to 200.
Under Advanced, set Expected body contains to "code":0 (SRS API responses include "code":0 for success).
Click Save.

A failure on this endpoint means the SRS process has crashed or the HTTP API module has stopped responding. Enable the HTTP API in your SRS config:

# srs.conf
http_api {
    enabled     on;
    listen      1985;
}

Step 2: Monitor the RTMP Ingest Port (1935)

RTMP is the primary ingest protocol for live streaming — used by OBS, ffmpeg, and hardware encoders. Port 1935 being unreachable means publishers can't connect and all streams go dark immediately.

Click Add Monitor → TCP Port.
Host: YOUR_SRS_HOST, Port: 1935.
Set Check interval to 1 minute.
Click Save.

A TCP failure on port 1935 is a hard outage for all stream publishers. Combined with the HTTP API monitor, you can distinguish between "SRS process is down" (both fail) and "RTMP port is lost but HTTP API is up" (port binding issue or firewall change).

Step 3: Monitor the HLS Delivery Endpoint

SRS serves HLS streams over HTTP (or HTTPS). The HLS master playlist endpoint confirms that SRS is actively generating segments and the HTTP server is responsive to viewer requests. Monitor the HLS index for a known stream:

Click Add Monitor → HTTP / HTTPS.
URL: http://YOUR_SRS_HOST:8080/live/livestream.m3u8 (adjust the stream path to match your SRS vhost and stream name)
Set Check interval to 2 minutes.
Set Expected HTTP status to 200.
Click Save.

If no active stream is publishing, SRS returns 404 for the playlist — use the HTTP API endpoint (/api/v1/streams) to check for active streams instead:

http://YOUR_SRS_HOST:1985/api/v1/streams

Set Expected body contains to "total_connections" to confirm the stream API is returning data.

Step 4: Monitor the WebRTC Signaling Port (1985)

SRS's WebRTC signaling runs over HTTP on port 1985 — the same port as the HTTP API but on a different path (/rtc/v1/play/, /rtc/v1/publish/). A dedicated TCP monitor on port 1985 confirms the signaling interface is reachable:

Click Add Monitor → TCP Port.
Host: YOUR_SRS_HOST, Port: 1985.
Set Check interval to 1 minute.
Click Save.

If you've separated WebRTC onto a different port or host, update the monitor accordingly. The HTTP API monitor (Step 1) also covers this port for HTTP-level checks, so the TCP monitor here is a lower-level network reachability check.

Step 5: SSL Certificate Alerts for HTTPS HLS and WebRTC

HTTPS is required for WebRTC in browsers (the WebRTC API is only available in secure contexts), and HLS over HTTPS is standard for production deployments. An expired TLS certificate breaks both video playback and WebRTC sessions for all viewers simultaneously.

Add SSL monitoring to your HTTPS endpoints:

For HTTPS HLS delivery:

Click Add Monitor → HTTP / HTTPS.
URL: https://YOUR_SRS_HOST/live/livestream.m3u8 (or your HTTPS HLS base URL).
Set Expected HTTP status to 200.
Enable Monitor SSL certificate.
Set Alert when certificate expires in less than 21 days.
Click Save.

For the HTTPS WebRTC API:

Open the HTTP API monitor you created in Step 1 (or create a new one for https://YOUR_SRS_HOST:1985/api/v1/versions if HTTPS is enabled on the API port).
Enable Monitor SSL certificate.
Set Alert when certificate expires in less than 21 days.
Click Save.

SRS can use Let's Encrypt certificates via its built-in HTTPS support — configure automatic renewal with certbot or cert-manager to avoid the expiry scenario.

Step 6: Heartbeat Monitoring for Stream Publishing Health

The HTTP API and TCP port monitors confirm SRS is running, but they don't verify that stream publishing and transcoding are working end-to-end. Use a heartbeat monitor combined with a test stream publisher to validate the full ingest pipeline.

In Vigilmon:

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

Create a lightweight test publisher script using ffmpeg:

#!/bin/bash
# stream_health_check.sh — run every 5 minutes via cron

SRS_HOST="YOUR_SRS_HOST"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"

# Publish a 5-second test stream and check that SRS accepts it
ffmpeg -re -f lavfi -i testsrc=duration=5:size=320x240:rate=10 \
  -f lavfi -i sine=frequency=440:duration=5 \
  -c:v libx264 -preset ultrafast -tune zerolatency \
  -c:a aac \
  -f flv rtmp://${SRS_HOST}/live/healthcheck \
  -loglevel quiet 2>&1

if [ $? -eq 0 ]; then
  # Verify SRS recorded the stream in its API
  STREAMS=$(curl -s "http://${SRS_HOST}:1985/api/v1/streams" | grep -c "healthcheck" || echo "0")
  if [ "$STREAMS" -gt "0" ] || [ $? -eq 0 ]; then
    curl -s "$HEARTBEAT_URL"
  fi
fi

Add to cron:

# /etc/cron.d/srs-heartbeat
*/5 * * * * srs /usr/local/bin/stream_health_check.sh > /dev/null 2>&1

If SRS stops accepting RTMP publishes — even while the API port returns 200 — the heartbeat stops and Vigilmon alerts after 5 minutes.

Step 7: Configure Alert Channels

Go to Alert Channels in Vigilmon and add your preferred channel (Slack, email, or webhook).
Set Consecutive failures before alert to 2 on the HLS delivery monitor — HLS segments have a 2–6 second latency and a single missed probe during segment rotation is expected.
Group RTMP, HLS, and WebRTC monitors under a "SRS Media Server" service group so a full outage generates a single grouped alert.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP API | :1985/api/v1/versions | SRS process crash, API failure | | TCP RTMP | :1935 | RTMP ingest port down | | HTTP HLS | /live/stream.m3u8 | HLS delivery failure | | TCP WebRTC | :1985 | WebRTC signaling port unreachable | | SSL certificate | HTTPS HLS/WebRTC domain | Cert expiry, TLS renewal failure | | Cron heartbeat | RTMP publish test | Full ingest pipeline broken |

SRS serves live content where every second of downtime is visible to your entire audience simultaneously. With Vigilmon monitoring the HTTP API, RTMP ingest port, HLS delivery, WebRTC signaling, and a live publish heartbeat, you'll detect failures in under a minute — before your viewers see a black screen.