tutorial

Monitoring Screego with Vigilmon

Screego is a self-hosted screen sharing server for developers — but WebRTC infrastructure is notoriously fragile. Here's how to monitor Screego's web server, TURN/STUN service, signaling layer, and session API with Vigilmon.

Screego is a self-hosted screen sharing service built for developers. It runs on port 5050, uses WebRTC for peer-to-peer video streams, and provides a TURN server for users behind NAT. When Screego works, it's seamless. When it doesn't — because the TURN server is unreachable, the signaling WebSocket drops, or the Go HTTP server runs out of file descriptors — users are staring at a blank sharing screen with no explanation. Vigilmon gives you monitoring across every layer of this WebRTC stack.

What You'll Set Up

  • HTTP uptime monitor for the Screego web server
  • TURN/STUN service health check
  • Session signaling server availability monitor
  • User authentication endpoint monitor
  • Room creation API response time monitoring

Prerequisites

  • Screego running and accessible (default port 5050)
  • TURN server configured (either Screego's built-in TURN or a separate coturn instance)
  • A free Vigilmon account

Step 1: Monitor the Screego Web Server

Screego's main web interface serves the React frontend and proxies API requests. Start here:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the URL: https://screego.yourdomain.com (or http://your-server:5050 for direct access).
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

If you're running Screego behind nginx or Caddy, also check that the proxy is correctly forwarding WebSocket upgrade requests — this matters for the signaling server (Step 3).

Verify your setup:

curl -I https://screego.yourdomain.com
# HTTP/2 200
# content-type: text/html

Step 2: Monitor the TURN/STUN Service Health

Screego's built-in TURN server runs on UDP/TCP port 3478 by default (configurable via SCREEGO_TURN_PORT). Without a reachable TURN server, users behind symmetric NAT or firewalls cannot establish WebRTC connections.

Add a TCP monitor for the TURN service:

  1. In Vigilmon, click Add MonitorTCP Port.
  2. Enter your server's IP or hostname.
  3. Set Port to 3478 (or your configured TURN port).
  4. Set Check interval to 2 minutes.
  5. Click Save.

If you're using a separate coturn instance, add a monitor for that host's port instead.

Also confirm the TURN port is reachable from the public internet — TURN only helps remote users if it's not firewalled:

# From a remote machine
nc -zv your-server 3478
# Connection to your-server 3478 port [tcp/*] succeeded!

For the UDP TURN path, use a WebRTC connectivity test tool (like Trickle ICE) to verify end-to-end — Vigilmon's TCP check confirms the port is open, while periodic functional tests confirm the TURN relay actually works.


Step 3: Monitor the Session Signaling Server

Screego's signaling layer uses WebSockets to coordinate WebRTC session setup between participants. The signaling endpoint is typically at /api/socket or a similar path.

Add a monitor for the signaling health:

  1. In Vigilmon, add an HTTP / HTTPS monitor.
  2. URL: https://screego.yourdomain.com/api/login (or the equivalent API base path for your Screego version).
  3. Set Expected HTTP status to 200 or 401 (an unauthenticated probe to the API confirms the server is routing correctly).
  4. Set Check interval to 1 minute.
  5. Click Save.

To monitor the WebSocket signaling path specifically, use a cron heartbeat backed by a health check script:

#!/bin/bash
# Check WebSocket upgrade is accepted
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  -H "Upgrade: websocket" \
  -H "Connection: Upgrade" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Version: 13" \
  https://screego.yourdomain.com/api/socket)

# 101 = Switching Protocols (WebSocket accepted), 4xx = server-side error
if [ "$RESPONSE" = "101" ] || [ "$RESPONSE" = "400" ]; then
  # 400 can be expected if the server rejects the bare upgrade without auth
  curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID
fi

Run this every 5 minutes from cron to confirm the WebSocket path is alive.


Step 4: Monitor the User Authentication Endpoint

Screego supports password authentication via SCREEGO_AUTH_MODE. The login endpoint needs to be responsive for users to start or join sessions.

  1. Add an HTTP / HTTPS monitor.
  2. URL: https://screego.yourdomain.com/api/login
  3. Method: POST (or GET if Vigilmon is checking for endpoint reachability).
  4. Set Expected HTTP status to 400 or 401 — a probe without credentials returns an auth error, but confirms the endpoint is responding.
  5. Set Check interval to 1 minute.
  6. Click Save.

You can also verify Screego's health endpoint if your version exposes one:

curl -s https://screego.yourdomain.com/api/health

Check the Screego GitHub repository for the API surface available in your installed version.


Step 5: Monitor Room Creation API Response Times

A slow room creation API means users experience delays when starting a share session. Vigilmon tracks response time for every check — set up an alert when it degrades:

  1. Open the HTTP / HTTPS monitor for https://screego.yourdomain.com.
  2. Under Response time, set Alert if response time exceeds 2000 ms.
  3. Click Save.

For deeper insight, configure a synthetic room creation probe. If Screego exposes a public API for room management, you can POST to it with test credentials:

# Probe room creation endpoint (adjust path to your Screego version's API)
curl -s -X POST https://screego.yourdomain.com/api/rooms \
  -H "Content-Type: application/json" \
  -b "session=YOUR_SESSION_COOKIE" \
  -d '{"id":"healthcheck"}' \
  -w "\n%{time_total}"

Track this response time from a cron job and send the result to a Vigilmon heartbeat — silence means the probe timed out.


Step 6: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack or email.
  2. Set Consecutive failures before alert to 2 for the web server and API monitors.
  3. Set it to 1 for the TURN port monitor — a single failure means users behind NAT can't connect at all.
  4. Create a maintenance window in Vigilmon before restarting Screego or updating the TURN configuration to suppress false alerts.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web server | https://screego.yourdomain.com | Screego process crash, reverse proxy failure | | TURN port | :3478 TCP | TURN server down, firewall change | | Signaling API | /api/login | WebSocket routing failure, auth service down | | Response time | Web server | Go runtime slowdown, resource exhaustion | | Cron heartbeat | Heartbeat URL | WebSocket upgrade failures, signaling freeze |

Screego's WebRTC stack has more moving parts than a standard HTTP service — the TURN server, signaling WebSocket, and HTTP API all need to be healthy for a screen share to succeed. Vigilmon's combination of TCP port checks, HTTP monitors, and cron heartbeats covers all three layers, so you find out about breakage from a monitor alert instead of a team member's Slack message.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →