Monitoring Wetty Web SSH Terminal with Vigilmon

Wetty (Web + TTY) bridges the gap between SSH and the browser — your team gets a full terminal without an SSH client, and you keep SSH traffic off the public internet. But when Wetty's Node.js process silently crashes or the SSH server it connects to becomes unreachable, nobody knows until they try to open a terminal and get nothing. Vigilmon fills that gap with HTTP availability checks for the Wetty UI, redirect health monitoring, SSH backend TCP probes, SSL certificate alerts, and heartbeat confirmation of end-to-end session establishment.

What You'll Set Up

• HTTP uptime monitor for the Wetty web UI (/wetty/ endpoint)
• Base URL redirect health check confirming routing is configured correctly
• TCP probe for the SSH backend Wetty connects to
• SSL certificate expiry alert for HTTPS Wetty deployments
• Heartbeat monitor for end-to-end Wetty session establishment

Prerequisites

• Wetty installed and running (port 3000 by default, serving at /wetty/)
• SSH server accessible to the Wetty host
• A domain or IP accessible from the internet (or from Vigilmon's probe network)
• A free Vigilmon account

Step 1: Monitor the Wetty Web UI

Wetty serves the login form or xterm.js terminal UI at /wetty/ on port 3000. A 200 OK on GET /wetty/ confirms the Node.js Express server is running and the Wetty middleware is mounted correctly.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: http://your-server:3000/wetty/ (or https://your-terminal.domain.com/wetty/ if behind a reverse proxy).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

If you've changed the Wetty base path with --base /custom/, update the URL to match. The /wetty/ path (or your custom base) is where the actual terminal UI lives — a 200 there confirms both the server is up and the route is correctly registered.

Step 2: Base URL Redirect Health Check

A GET / on a default Wetty installation returns a 301 or 302 redirect to /wetty/. This redirect is the entry point most users visit, and a broken redirect means users land on a 404 or a blank page instead of the terminal.

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://your-server:3000/.
3. Set Expected HTTP status to 301 (or 302 depending on your Wetty version).
4. Set Follow redirects to off — you want to verify the redirect itself, not the final destination.
5. Set Check interval to 1 minute.
6. Click Save.

If you've configured Wetty behind a reverse proxy, the redirect behavior may be handled at the proxy level. In that case, check https://your-terminal.domain.com/ for the redirect from your domain root to /wetty/.

Step 3: SSH Backend TCP Probe

Wetty's core job is bridging the browser to an SSH server. If the SSH server becomes unreachable — even though Wetty itself is running fine — every session attempt will fail at the connection stage. A TCP probe to the SSH port confirms the backend Wetty depends on is available.

1. Click Add Monitor → TCP Port.
2. Enter the SSH server hostname (typically localhost or the IP of your SSH server).
3. Set Port to 22 (or the custom SSH port your Wetty is configured to connect to with --sshport).
4. Set Check interval to 1 minute.
5. Click Save.

For remote SSH targets (Wetty connecting to a separate host, not localhost), set the target to that remote host's address. This probe fires before a user even tries to log in, giving you advance warning of SSH connectivity failures.

Step 4: SSL Certificate Alerts for HTTPS Deployments

Wetty is typically reverse-proxied behind nginx, Apache, or Caddy for SSL termination. A certificate expiry silently breaks browser-based terminal access — browsers refuse the connection and users see a TLS error instead of a terminal.

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

1. Open the monitor for your Wetty URL.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

For nginx with Let's Encrypt, renewal failures are common when port 80 is blocked or when the certbot cron job is misconfigured. A 21-day alert window gives you time to investigate and renew manually if needed:

# Check certificate status
certbot certificates

# Manual renewal if auto-renew failed
certbot renew --cert-name your-terminal.domain.com

Step 5: Heartbeat Monitoring for Session Establishment

Wetty's HTTP check confirms the server is running, but a session could still fail if SSH authentication is broken, the target user account is locked, or the SSH server's host key changed. A server-side script that exercises the full Wetty → SSH login path and pings a Vigilmon heartbeat on success gives you end-to-end confidence.

Create the heartbeat monitor

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 10 minutes.
3. Copy the heartbeat URL: https://vigilmon.online/heartbeat/YOUR_TOKEN.

Create a session health check script

#!/bin/bash
# /usr/local/bin/wetty-health-check.sh
# Checks that Wetty is serving the terminal UI and SSH port is reachable

WETTY_URL="http://localhost:3000/wetty/"
SSH_HOST="localhost"
SSH_PORT="22"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_TOKEN"

# Check Wetty web UI
wetty_ok=$(curl -sf --max-time 5 -o /dev/null -w "%{http_code}" "$WETTY_URL")
if [ "$wetty_ok" != "200" ]; then
    echo "Wetty UI check failed: HTTP $wetty_ok"
    exit 1
fi

# Check SSH backend is reachable
if ! nc -z -w 3 "$SSH_HOST" "$SSH_PORT" 2>/dev/null; then
    echo "SSH backend unreachable at $SSH_HOST:$SSH_PORT"
    exit 1
fi

# Both checks passed — signal Vigilmon
curl -sf "$HEARTBEAT_URL" > /dev/null

Schedule the check

# Add to crontab: crontab -e
*/10 * * * * /usr/local/bin/wetty-health-check.sh

Make the script executable:

chmod +x /usr/local/bin/wetty-health-check.sh

If either check fails, the heartbeat won't be sent and Vigilmon alerts after the expected interval.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add email, Slack, or a webhook.
2. On the Wetty UI monitor and base URL redirect monitor, set Consecutive failures before alert to 2 — Node.js startup after a process manager restart takes a few seconds.
3. On the SSH TCP probe, set Consecutive failures before alert to 1 — an unreachable SSH server is an immediate problem, not a transient blip.

If you deploy Wetty updates or restart the service regularly, pause alerts during maintenance:

# Open a 5-minute maintenance window before restarting Wetty
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 5}'

pm2 restart wetty
# or: systemctl restart wetty

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP uptime | /wetty/ on port 3000 | Wetty process crash, route misconfiguration | | Base URL redirect | GET / → 301/302 | Broken redirect, users landing on 404 | | SSH TCP probe | SSH host port 22 | SSH backend unreachable, auth server down | | SSL certificate | Wetty HTTPS domain | Certificate expiry blocking browser access | | Cron heartbeat | Heartbeat URL | Session establishment failure, SSH auth broken |

Wetty removes the need for an SSH client — but it adds a web server, a reverse proxy, and an SSH connection to your uptime surface. Vigilmon watches every layer: the Node.js server, the routing, the SSH backend, the TLS certificate, and the actual session path. When any one of them silently fails, you know before your users do.