tutorial

Monitoring RustDesk Server with Vigilmon

RustDesk is your self-hosted remote desktop infrastructure — but if the relay or rendezvous server goes down, every remote session across your fleet stops connecting. Here's how to monitor RustDesk's TCP ports, web console, heartbeat, and SSL certificates with Vigilmon.

RustDesk is a popular open-source remote desktop application written in Rust — a self-hosted alternative to TeamViewer and AnyDesk that gives you full control over your relay infrastructure. When your self-hosted RustDesk server goes down, no one on your team can connect remotely until someone manually restores the service. Vigilmon gives you continuous monitoring for RustDesk's relay port (21117), ID/rendezvous server ports (21115/21116), web console availability, process heartbeat, and SSL certificate alerts for your HTTPS console — so you know the moment something breaks, not when a developer calls saying they can't reach a production server.

What You'll Set Up

  • TCP port monitoring for the RustDesk relay server (port 21117)
  • TCP port monitoring for the ID/rendezvous server (ports 21115 and 21116)
  • HTTP uptime monitor for the RustDesk web console (if enabled)
  • Heartbeat monitoring for the RustDesk server process
  • SSL certificate alerts for HTTPS web console setups

Prerequisites

  • hbbs (ID/rendezvous server) and hbbr (relay server) running on your VPS or dedicated host
  • RustDesk server accessible over TCP from the internet
  • A free Vigilmon account

Step 1: Monitor the Relay Server TCP Port (21117)

The relay server (hbbr) handles the actual data relay between RustDesk clients when a direct peer-to-peer connection isn't possible. Port 21117 carries relayed remote desktop traffic. If this port goes dark, relayed sessions fail to establish.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to TCP Port.
  3. Set Host to your RustDesk server's hostname or IP address.
  4. Set Port to 21117.
  5. Set Check interval to 1 minute.
  6. Click Save.

Verify the port is listening on your server:

# Check that hbbr is listening on 21117
ss -tlnp | grep 21117
# or
netstat -tlnp | grep 21117

A successful TCP connection to port 21117 confirms the relay server process is running and accepting connections. A failure means either hbbr has crashed, the firewall is blocking the port, or the server itself is unreachable.

Step 2: Monitor the ID/Rendezvous Server Ports (21115 and 21116)

The ID server (hbbs) runs on two ports:

  • Port 21115 — TCP, used for NAT type testing and peer discovery
  • Port 21116 — TCP and UDP, used for the ID registration/rendezvous protocol

Without the ID server, RustDesk clients can't look up each other by their IDs, and no new sessions can be established — even if the relay server is running.

Add TCP monitors for both ports:

Port 21115:

  1. In Vigilmon, click Add Monitor → TCP Port.
  2. Set Host to your server hostname or IP.
  3. Set Port to 21115.
  4. Set Check interval to 1 minute.
  5. Click Save.

Port 21116:

  1. Repeat the above with Port set to 21116.
  2. Click Save.

Note: Port 21116 also uses UDP for the rendezvous protocol. TCP monitoring confirms the process is listening, but UDP availability requires a RustDesk client test. If clients consistently fail to find each other by ID while TCP port checks pass, investigate UDP firewall rules:

# Check firewall rules for UDP 21116
sudo ufw status | grep 21116
# or for iptables
sudo iptables -L INPUT -n | grep 21116

Step 3: Monitor the Web Console (if hbbs is configured with API)

Recent versions of RustDesk server (hbbs) can expose a web-based administration console for managing access control, user groups, and device lists. If you've enabled this feature, add an HTTP monitor for the web console port (typically port 21114 or a custom port behind a reverse proxy).

  1. In Vigilmon, click Add Monitor → HTTP / HTTPS.
  2. Set the URL to your web console address:
    • Direct: http://your-server-ip:21114
    • Reverse proxy: https://rustdesk-admin.yourdomain.com
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 1 minute.
  5. Click Save.

Add a keyword check for a string that only appears in the RustDesk console login page (e.g., RustDesk) to confirm you're getting the actual application rather than a reverse proxy error:

# Verify the web console is serving content
curl -sk https://rustdesk-admin.yourdomain.com | grep -i rustdesk

If you haven't exposed the web console publicly, you can deploy a minimal health check endpoint on the same host using a small nginx stub:

location /rustdesk-health {
    access_log off;
    return 200 '{"status":"ok"}';
    add_header Content-Type application/json;
}

Step 4: SSL Certificate Alerts for HTTPS Console Setup

If your RustDesk web console is served over HTTPS via a reverse proxy (nginx, Caddy, or Traefik), a certificate expiry makes the admin interface inaccessible and may confuse RustDesk clients configured to use the signed domain.

  1. Open the HTTPS monitor created in Step 3.
  2. Enable Monitor SSL certificate under the SSL section.
  3. Set Alert when certificate expires in less than 21 days.
  4. Click Save.

For Caddy-managed certificates (Caddy auto-renews by default), check renewal status:

# Check Caddy's certificate store
sudo caddy list-certificates 2>/dev/null || \
  ls -la /var/lib/caddy/.local/share/caddy/certificates/

For Let's Encrypt via certbot:

sudo certbot certificates
sudo certbot renew --dry-run

For nginx with a manually managed certificate, the Vigilmon 21-day window is your primary renewal reminder. When it fires, redeploy the certificate:

# Copy renewed certificate to nginx
sudo cp /etc/letsencrypt/live/rustdesk-admin.yourdomain.com/fullchain.pem /etc/nginx/ssl/
sudo cp /etc/letsencrypt/live/rustdesk-admin.yourdomain.com/privkey.pem /etc/nginx/ssl/
sudo nginx -t && sudo systemctl reload nginx

Step 5: Heartbeat Monitoring for the RustDesk Server Process

TCP port checks confirm that ports are open, but they don't verify that hbbs and hbbr are processing requests correctly. A process can be in a zombie state, deadlocked, or out of memory while still holding open its listening sockets. Use Vigilmon's cron heartbeat to verify that the processes are actively running and healthy.

Create a simple health check script that sends a heartbeat only when both processes are confirmed running:

# /usr/local/bin/rustdesk-healthcheck.sh
#!/bin/bash
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"

# Check that both hbbs and hbbr are running
if pgrep -x hbbs > /dev/null && pgrep -x hbbr > /dev/null; then
    curl -s "$HEARTBEAT_URL"
fi

Make it executable and schedule it with cron:

chmod +x /usr/local/bin/rustdesk-healthcheck.sh

# Add to crontab — run every minute
crontab -e
# Add:
* * * * * /usr/local/bin/rustdesk-healthcheck.sh

In Vigilmon:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 1 minute.
  3. Use the heartbeat URL in your script above.
  4. Click Save.

If either hbbs or hbbr crashes, the script sends no ping and Vigilmon alerts after 1 minute. This catches process crashes that don't immediately close listening sockets, as well as cases where both processes have died entirely.

For systemd-managed RustDesk installations, you can also add ExecStartPost and OnFailure directives to the service unit for richer failure detection:

# /etc/systemd/system/rustdesk-hbbs.service
[Unit]
Description=RustDesk ID Server
After=network.target

[Service]
ExecStart=/usr/bin/hbbs
Restart=always
RestartSec=10
ExecStopPost=/bin/bash -c 'curl -s https://vigilmon.online/heartbeat/fail-abc123 || true'

[Install]
WantedBy=multi-user.target

Step 6: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
  2. For TCP port monitors (21115, 21116, 21117), set Consecutive failures before alert to 2 — a single missed TCP check can occur during hbbr/hbbs restart after a systemd service reload.
  3. For the process heartbeat monitor, set Consecutive failures to 1 — a single missed heartbeat means at least one process has been down for a full minute.
  4. Route alerts to wherever your on-call team will see them immediately. A RustDesk outage at 2 AM means no one can remotely access any server until the service is restored.

For teams using RustDesk as their primary remote access tool, consider a redundant monitoring setup:

# Notify both Slack and SMS on relay port failure
# Configure multiple alert channels in Vigilmon and assign both to the 21117 TCP monitor

Use Maintenance windows when upgrading RustDesk server binaries:

# Open maintenance window (typically 2-3 minutes for hbbr/hbbs restart)
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "abc123", "duration_minutes": 5}'

# Stop, replace, and restart RustDesk
sudo systemctl stop rustdesk-hbbr rustdesk-hbbs
sudo cp hbbr hbbs /usr/bin/
sudo systemctl start rustdesk-hbbs rustdesk-hbbr

Summary

| Monitor | Target | What It Catches | |---|---|---| | TCP relay port | :21117 | hbbr crash, firewall blocking relay | | TCP rendezvous | :21115, :21116 | hbbs crash, peer discovery failure | | Web console | https://rustdesk-admin.yourdomain.com | Console unavailable, reverse proxy failure | | SSL certificate | Console domain | Certificate expiry, renewal failure | | Process heartbeat | Heartbeat URL | Zombie process, both services down |

Self-hosting RustDesk gives you complete control over your remote access infrastructure — but it also means you're the one who gets the midnight call when nobody can log into a production server. With Vigilmon watching every port and process, you'll know within a minute of any failure and can restore access before it becomes a crisis.

Monitor your app with Vigilmon

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

Start free →
← Back to all articles