How to Monitor WG-Easy with Vigilmon (Web Dashboard, VPN Endpoint, and Peer Connectivity)

WG-Easy is a self-hosted WireGuard VPN manager with a built-in web UI that makes it easy to add clients, generate QR codes, and monitor peer connections — all without touching the WireGuard CLI directly. It's widely used by homelab operators and small teams who need a simple, zero-maintenance VPN for secure remote access. But when WG-Easy goes down, remote workers and off-site services lose VPN access entirely, and diagnosing the failure often requires the very VPN access that's broken.

In this tutorial you'll set up end-to-end monitoring for WG-Easy using Vigilmon — free tier, no credit card required.

Why WG-Easy needs dedicated monitoring

WG-Easy is a thin layer over WireGuard, which means its failure modes span both the management UI and the underlying VPN protocol:

Web UI process crash — WG-Easy is a Node.js application. If the process crashes, peer management is unavailable and no new clients can be added or reconfigured, even if the WireGuard tunnel itself is still routing traffic
WireGuard UDP endpoint unreachable — a firewall rule change, ISP block, or kernel module issue can take the VPN endpoint offline while the web UI remains healthy. Peers lose connectivity silently; they just stop routing traffic through the tunnel
Docker container restart loops — WG-Easy is commonly deployed in Docker. A container in a crash-restart loop appears "running" at the Docker level but serves no traffic
Port conflicts — the web UI default port (51821) and the WireGuard UDP port (51820) are close together. Misconfiguration or conflicts with other services can cause either to stop binding without surfacing an obvious error
Configuration corruption — WG-Easy stores its configuration in a JSON file mounted into the container. If this file becomes corrupt or unreadable, WG-Easy fails to start or starts with an empty peer list

Monitoring from outside your network gives you visibility that's independent of the VPN — so you can know your VPN is down even when you can't reach it to diagnose the problem.

What you'll need

A running WG-Easy instance (Docker or standalone, version 7.0 or later)
A free Vigilmon account (sign-up takes 30 seconds)
Your WG-Easy server's public IP or hostname
Default ports: 51821 (web UI / HTTP), 51820 (WireGuard UDP)

Step 1: Verify the WG-Easy web dashboard is accessible

WG-Easy serves its management interface at port 51821 by default. The root path returns the dashboard, which you can use as an HTTP health target.

Test it:

curl -sf http://your-server-ip:51821/
# or if behind a reverse proxy with HTTPS:
curl -sf https://vpn.example.com/

If you're exposing WG-Easy through a reverse proxy (nginx, Caddy, Traefik), use the proxied URL for monitoring — that's the actual path your users and admin take.

Step 2: Set up HTTP monitoring for the web dashboard

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the monitor type
Set the URL to your WG-Easy dashboard: https://vpn.example.com/ (or http://your-server-ip:51821/)
Set the check interval to 1 minute
Under Expected response, configure:
- Status code: 200
Save the monitor

Vigilmon will probe the web UI every minute. If the Node.js process crashes, the Docker container stops, or the reverse proxy misconfigures, the monitor fires within 60 seconds.

Step 3: Monitor the WireGuard UDP endpoint

HTTP checks verify the management UI is up. But your VPN clients connect over UDP port 51820 — and that port can go down independently of the web UI. WireGuard uses UDP, which Vigilmon monitors via TCP check on the same port (useful for detecting whether the port is bound and responding, though the VPN handshake itself is protocol-specific).

For a more reliable VPN endpoint check, monitor the server's reachability using an HTTP check on a service that only routes through the VPN, or use TCP on a TCP port your server exposes to VPN clients.

However, for public endpoint reachability, the most practical approach is:

In Vigilmon, go to Monitors → New Monitor
Choose TCP Port
Enter your WireGuard server hostname: your-server.example.com
Enter port: 51820
Set check interval to 1 minute
Save the monitor

Note: WireGuard uses UDP, not TCP. A TCP port check on 51820 won't validate the WireGuard handshake — it will validate that something is listening on that port. For a true VPN endpoint health check, see Step 4.

Step 4: Validate VPN connectivity with a through-tunnel heartbeat

The most reliable way to verify WireGuard connectivity end-to-end is to run a heartbeat monitor from inside your VPN network. Set up a simple script on a device that's always connected to the VPN (a home server, Raspberry Pi, or always-on VM) that pings Vigilmon on a schedule:

#!/bin/bash
# /usr/local/bin/vpn-connectivity-check.sh
# Runs every 5 minutes via cron on a VPN-connected device

# Check that we can reach an internal resource only accessible via VPN
if ping -c 1 -W 3 10.8.0.1 > /dev/null 2>&1; then
  # VPN gateway is reachable — signal heartbeat
  curl -sf "https://heartbeat.vigilmon.online/ping/your-heartbeat-id"
fi

Add to cron on your always-on VPN client:

*/5 * * * * /usr/local/bin/vpn-connectivity-check.sh

Set up the Vigilmon heartbeat monitor:

In Vigilmon, go to Monitors → New Monitor
Choose Heartbeat
Name it: "WireGuard VPN connectivity"
Set expected interval to 5 minutes
Save the monitor and copy the ping URL into your script

If the VPN tunnel drops — even if the web UI stays healthy — the heartbeat stops and Vigilmon alerts you after the grace period.

Step 5: Monitor the server's public IP and DNS

WireGuard clients connect to your server's public IP or hostname. If that IP changes (dynamic DNS, ISP reassignment) or the DNS record goes stale, existing peers lose connectivity.

In Vigilmon, go to Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to a stable HTTP service on your public IP (e.g., your server's public web port or the WG-Easy UI): https://vpn.example.com/
The existing HTTP monitor from Step 2 already covers this if you're using a DNS name

If you're using a dynamic DNS service (DuckDNS, ddclient, Cloudflare), make sure your DDNS updater runs on a schedule and consider adding a heartbeat monitor for it as well.

Step 6: Set up SSL certificate monitoring (if using HTTPS)

If you expose the WG-Easy web UI over HTTPS through a reverse proxy, add SSL certificate monitoring. An expired certificate will lock you out of the management UI at the worst possible time.

In Vigilmon, go to Monitors → New Monitor
Choose SSL Certificate
Enter your WG-Easy domain: vpn.example.com
Set warning threshold to 30 days
Save the monitor

Step 7: Configure alert channels

A VPN outage is often time-sensitive — remote engineers can't access internal resources, and the monitoring infrastructure itself may route over the VPN. Alert delivery should be fast and reach multiple channels.

Webhook (Slack, Discord, PagerDuty):

Go to Alert Channels → Add Channel → Webhook
Enter your webhook URL
Assign to all WG-Easy monitors

Email (as a fallback):

Go to Alert Channels → Add Channel → Email
Add a personal or team email that's reachable without the VPN
Assign to all monitors

Make sure your alert destination is reachable without the VPN — an alert that routes over the VPN you're trying to monitor is useless when the VPN is down.

Example Vigilmon alert payload:

{
  "monitor_name": "WG-Easy web dashboard",
  "status": "down",
  "url": "https://vpn.example.com/",
  "started_at": "2026-04-01T08:12:00Z",
  "duration_seconds": 180
}

Step 8: Build a VPN status page

If you have multiple remote team members or services that depend on VPN access, a status page gives them a self-service way to check whether the VPN is the problem.

In Vigilmon, go to Status Pages → New Status Page
Name it "VPN Infrastructure" or "WG-Easy Status"
Add your monitors: web dashboard HTTP, VPN connectivity heartbeat, SSL cert
Make the page publicly accessible (or at least accessible without VPN, from any IP)
Publish and share the URL with your team

When remote workers can't connect, they check the status page instead of filing a ticket or pinging the on-call engineer.

Recommended monitor summary

| Monitor | Type | Interval | Checks for | |---|---|---|---| | https://vpn.example.com/ | HTTP | 1 min | Web UI process, reverse proxy | | your-server.example.com:51820 | TCP | 1 min | Port bound and reachable | | WireGuard VPN connectivity | Heartbeat | 5 min | End-to-end VPN tunnel | | vpn.example.com | SSL | daily | Certificate expiry |

Docker Compose tip: add a restart policy

If you're running WG-Easy in Docker, make sure your docker-compose.yml has a restart policy so container crashes trigger automatic recovery while Vigilmon alerts you:

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy
    container_name: wg-easy
    environment:
      WG_HOST: vpn.example.com
      PASSWORD: ${WGEASY_PASSWORD}
      WG_DEFAULT_DNS: 1.1.1.1
    volumes:
      - ./wg-easy-data:/etc/wireguard
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

The restart: unless-stopped policy handles transient crashes. Vigilmon handles the persistent failures that Docker can't self-heal.

What's next

Peer activity monitoring — WG-Easy's API exposes per-peer last-seen timestamps. You can script a heartbeat that alerts when a specific peer (e.g., a critical remote server) hasn't been seen in over an hour
Response time tracking — Vigilmon logs web UI response times over time; a gradual increase can indicate the Docker host is under memory pressure before the container actually crashes

Get started free at vigilmon.online — no credit card, your first monitor is live in under a minute.