Monitoring Jitsi Meet with Vigilmon: Web Interface, XMPP Ports, HTTP Bind, Jicofo & SSL Alerts

Jitsi Meet is a self-hosted open-source video conferencing platform that gives distributed teams private, WebRTC-powered video calls on their own infrastructure. Engineering and operations teams choose Jitsi to eliminate SaaS meeting tool costs and to keep call data on-premises for compliance and privacy reasons. When Jitsi goes down, the impact is immediate and disruptive: teams trying to join a meeting get a blank page or "could not connect" error, and there is no fallback — the call simply does not happen. Jitsi's architecture has several independently-failable components: the Prosody XMPP server handles signalling, the Jicofo conference focus component manages call routing, and the Jitsi Videobridge (JVB) relays media. A failure in any one of them can break calls even if the web interface appears to load. Vigilmon gives you external visibility into Jitsi's web interface, XMPP TCP ports, HTTP bind endpoint, Jicofo health, and SSL certificate so failures are caught within 60 seconds — before your team's next meeting.

What You'll Build

• An HTTP monitor for the Jitsi Meet web interface
• TCP monitors for the Prosody XMPP server ports (5222 and 5280)
• An HTTP monitor for the XMPP HTTP bind endpoint (/http-bind)
• An HTTP monitor for the Jicofo health endpoint
• SSL certificate monitoring for your Jitsi domain
• An alerting setup tuned for meeting-critical availability

Prerequisites

• A running Jitsi Meet instance with a public or network-reachable domain
• HTTPS configured (e.g., https://meet.example.com)
• A free account at vigilmon.online

Step 1: Monitor the Jitsi Meet Web Interface

The Jitsi Meet web interface is the entry point for all participants — they navigate to your domain to start or join a meeting. When the web interface is unavailable, no one can start a call regardless of whether the underlying signalling and media services are healthy:

curl -i https://meet.example.com
# Expected: HTTP 200 with Jitsi HTML

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://meet.example.com.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: Jitsi.
7. Label: Jitsi Web Interface.
8. Click Save.

This monitor catches:

• nginx or reverse proxy failures that return 502/503 to meeting participants
• Static asset serving failures after a Jitsi upgrade that leave the page blank
• DNS resolution failures that prevent domain lookups
• Certificate validation failures that modern browsers block before any page renders

Why this matters for distributed teams: A Jitsi web interface failure at 9:00 AM means your entire remote team's standup is cancelled with no warning. The 60-second check interval gives you an alert before the first attendee reports a blank screen in chat.

Step 2: Create TCP Monitors for the XMPP Server Ports

Jitsi uses Prosody, an XMPP server, for real-time call signalling. Prosody listens on two ports that must be reachable for calls to connect:

• Port 5222 — direct XMPP client connections (used by Jicofo and JVB internally)
• Port 5280 — XMPP over HTTP (BOSH/WebSocket, used by browsers and the HTTP bind endpoint)

Monitor Port 5222

1. Add Monitor → TCP.
2. Host: meet.example.com.
3. Port: 5222.
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Jitsi XMPP Port 5222.
7. Click Save.

Monitor Port 5280

1. Add Monitor → TCP.
2. Host: meet.example.com.
3. Port: 5280.
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Jitsi XMPP Port 5280.
7. Click Save.

A TCP failure on either port means Prosody is down or unreachable. When Prosody is unavailable, browsers cannot complete the XMPP handshake needed to join a conference room — the web interface loads but the call never connects, and participants see a spinning "Connecting..." indicator until they time out.

Note: If your Jitsi deployment sits behind a firewall or load balancer that blocks direct TCP access from external probes, these ports may not be externally reachable. In that case, skip the TCP monitors and rely on the HTTP bind monitor (Step 3) as your Prosody health signal.

Step 3: Monitor the XMPP HTTP Bind Endpoint

The HTTP bind endpoint at /http-bind is the BOSH (Bidirectional streams Over Synchronous HTTP) endpoint that browsers use to communicate with the Prosody XMPP server. It is served through nginx on port 443 and proxied to Prosody on port 5280, making it the most reliable external signal for Prosody health:

curl -i https://meet.example.com/http-bind
# Expected: HTTP 200 (empty BOSH body — Prosody is alive and accepting connections)

1. Add Monitor → HTTP.
2. URL: https://meet.example.com/http-bind.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Label: Jitsi HTTP Bind.
7. Click Save.

A 200 response from /http-bind confirms that nginx is forwarding requests to Prosody and Prosody is responding. A 502 or 504 means the nginx-to-Prosody proxy is failing — Prosody may have crashed or the BOSH module may be disabled. A timeout means neither nginx nor Prosody are responding on the HTTPS path.

Step 4: Monitor the Jicofo Health Endpoint

Jicofo (Jitsi Conference Focus) is the component that manages conference room state: it allocates Jitsi Videobridge (JVB) instances for each call and coordinates participant signalling through Prosody. Jicofo exposes a health endpoint on port 8888 (internal) that reflects its connection to both Prosody and the JVB pool:

curl -i http://localhost:8888/about/health
# Expected: HTTP 200

Since Jicofo's health port is typically only accessible within your server, you have two options:

Option A — Expose via nginx (recommended): Add a location block in your nginx configuration to proxy /jicofo-health to localhost:8888/about/health, restricted to monitoring IPs or with a shared secret header, then monitor the proxied path:

1. Add Monitor → HTTP.
2. URL: https://meet.example.com/jicofo-health.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Label: Jicofo Health.
6. Click Save.

Option B — Indirect inference: If you cannot expose the Jicofo health port externally, monitor it indirectly by observing that calls fail to connect even though the web interface and HTTP bind endpoints are healthy — Jicofo failures cause a specific pattern where the room page loads but participants cannot be connected to a JVB. Set up a cron heartbeat monitor in Vigilmon and configure a test script that joins a Jitsi room programmatically and sends the heartbeat only on success.

Step 5: Monitor SSL Certificates

An expired SSL certificate on your Jitsi instance breaks every aspect of the platform simultaneously:

• The web interface becomes inaccessible to all participants (HTTPS required for WebRTC)
• WebRTC media fails — browsers refuse to establish peer connections through an untrusted certificate
• The XMPP over HTTPS path fails — browsers cannot reach /http-bind, preventing all signalling
• Any mobile Jitsi Meet apps connecting to your instance reject the certificate

1. Add Monitor → SSL Certificate.
2. Domain: meet.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

WebRTC and SSL: Unlike most web applications, Jitsi requires a valid SSL certificate not just for the web page but for the WebRTC connection itself. An expired certificate does not just show a browser warning — it causes WebRTC to refuse the ICE handshake, meaning no media flows at all even if a user clicks through the certificate warning to reach the page.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Web Interface | Non-200 or Jitsi missing | Check nginx/reverse proxy; verify static file serving; inspect container logs | | XMPP Port 5222 | Connection refused or timeout | Check Prosody service; inspect XMPP server logs; verify port binding | | XMPP Port 5280 | Connection refused or timeout | Check Prosody BOSH module; inspect HTTP module configuration | | HTTP Bind (/http-bind) | Non-200 response | Check Prosody health; inspect nginx BOSH proxy configuration | | Jicofo Health | Non-200 response | Check Jicofo service; inspect JVB pool connectivity; review Jicofo logs | | SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is functioning |

Alert after: 1 consecutive failure for all monitors — a Jitsi failure means active meetings are disrupted. Do not wait for 2 failures; a single missed check on a video conferencing system affects real people in real time.

Escalation for distributed teams: Route Jitsi alerts to your operations or IT on-call channel, not just infrastructure. A Jitsi failure at 8:55 AM before a scheduled 9:00 AM all-hands call needs immediate human response, not a ticket queue.

Common Jitsi Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | nginx crash or misconfiguration after update | Web interface monitor and HTTP bind monitor fire simultaneously | | Prosody XMPP server OOM-killed | TCP port 5222/5280 monitors and HTTP bind monitor fire | | Jicofo crash (calls connect but never start) | Jicofo health monitor fires; web interface appears healthy | | JVB crash (signalling works but no media) | Jicofo health may reflect JVB pool failure; calls start but go black | | SSL certificate expires | SSL monitor alerts at 30 days; all WebRTC and HTTPS access fails | | DNS misconfiguration | All HTTP monitors fire simultaneously | | Port 5222/5280 blocked by firewall rule change | TCP monitors fire; HTTP bind may still work via port 443 proxy | | Container restart loop after version upgrade | Health monitors intermittently return 503; flapping alerts | | Disk full (Prosody log growth) | Prosody crashes; TCP and HTTP bind monitors fire | | Let's Encrypt renewal failure | SSL monitor catches certificate approaching expiry |

Jitsi Meet is critical infrastructure for distributed teams — when it goes down, meetings simply do not happen, and there is no graceful degradation. Vigilmon watches Jitsi's web interface, XMPP signalling ports, HTTP bind endpoint, Jicofo health, and SSL certificate so you're alerted within 60 seconds of any failure, before the first team member reports a broken meeting link.

Start monitoring Jitsi in under 5 minutes — register free at vigilmon.online.