Monitoring WatchYourLAN with Vigilmon: Web UI, ARP Scan Health, Scan Freshness & SSL Alerts

WatchYourLAN is your eyes on the local network — continuously scanning via ARP to discover every device, tracking online/offline status, and alerting you when unknown devices connect or known devices go dark. When WatchYourLAN goes down, you lose visibility into your entire network: you won't know if a device went offline, an unauthorized device connected, or a network segment became unreachable. But the subtler failure is worse: WatchYourLAN can keep serving the web dashboard while its ARP scan loop has silently stalled — showing stale data that looks current. Vigilmon gives you external visibility into WatchYourLAN: web UI availability, API data freshness, and — most critically — whether the ARP scan loop is actually running.

What You'll Build

• A monitor on WatchYourLAN's web dashboard to catch Go server failures
• A monitor on the REST API to verify ARP scan data is being collected
• A heartbeat monitor that checks ARP scan freshness (detects stalled scan loops)
• SSL certificate monitoring for HTTPS WatchYourLAN deployments
• An alerting setup that distinguishes server failures from scan loop stalls

Prerequisites

• A running WatchYourLAN instance accessible via HTTP or HTTPS
• WatchYourLAN serving the web UI on port 8840 (default) or a custom port
• A free account at vigilmon.online

Step 1: Verify WatchYourLAN's Health Endpoints

WatchYourLAN is a lightweight Go application that serves the web UI and REST API on port 8840 by default. Verify it's accessible:

# Check web UI availability
curl -I http://watchyourlan.example.com:8840/

# Expect: HTTP 200 with the device list dashboard

# Check API endpoint
curl http://watchyourlan.example.com:8840/api/v1/hosts
# Returns JSON array of discovered hosts

The web dashboard at / returns HTTP 200 when the Go HTTP server is running and the SQLite database is readable. The API endpoint at /api/v1/hosts returns the current list of all ARP-discovered hosts with their IP, MAC, hostname, vendor, and last_seen timestamp.

SQLite health signal: If WatchYourLAN starts but the SQLite database is corrupted or the data file is inaccessible, the web UI may return errors. The API endpoint returning a valid JSON array (even empty) confirms both the HTTP server and the SQLite database are functioning.

Step 2: Create a Vigilmon HTTP Monitor for the Web UI

The web dashboard monitor confirms the Go HTTP server is running and the SQLite database is readable:

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: http://watchyourlan.example.com:8840/ (or your configured port/proxy URL).
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: WatchYourLAN (appears in the page title of the web dashboard).
7. Click Save.

This monitor catches:

• Go process crashes or container restarts
• SQLite database file corruption or missing data directory
• Port binding failures after host reboots
• Docker container exit (if running in Docker)

Alert sensitivity: Set alerts to trigger after 2 consecutive failures. The Go HTTP server is lightweight and stable; two consecutive failures reliably indicate a real failure rather than a transient network hiccup.

Step 3: Create a Vigilmon HTTP Monitor for the API

The API endpoint verifies that ARP scan data is being collected and stored. Monitor it separately from the UI to catch cases where the server is running but data collection has stopped:

1. Add Monitor → HTTP.
2. URL: http://watchyourlan.example.com:8840/api/v1/hosts.
3. Check interval: 5 minutes.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: A known MAC address of a device that should always be on your network (e.g., your router: aa:bb:cc:dd:ee:ff). Alternatively use last_seen which appears in every host entry.
7. Click Save.

Choosing a keyword: Pick the MAC address of a device that is always online — your router, NAS, or a static server. If this keyword disappears from the API response, it means either that device went offline or WatchYourLAN stopped seeing it. The last_seen keyword is a reliable fallback that confirms any ARP data is present.

Empty network: If your network scan returns zero hosts (uncommon but possible with interface configuration issues), the API returns [] — an empty JSON array. The keyword check on a known MAC address catches this case, which a simple HTTP 200 check would miss.

Step 4: Set Up Heartbeat Monitoring for ARP Scan Freshness

WatchYourLAN's most dangerous failure mode is a running process that has stopped scanning. The web UI serves stale data from SQLite, the API returns a 200 response with old host records — but the ARP scan loop has silently stopped due to network interface errors or permission issues. Set up a scheduled script that checks scan freshness:

In Vigilmon:

1. Add Monitor → Heartbeat.
2. Name: WatchYourLAN ARP scan freshness.
3. Expected interval: 5 minutes (2x the default 60-second scan interval with a generous buffer).
4. Grace period: 2 minutes.
5. Copy the generated heartbeat URL (e.g., https://api.vigilmon.online/heartbeat/abc123).

Create a cron job on the WatchYourLAN host (or any host with access):

# /usr/local/bin/watchyourlan-freshness-check.sh
#!/bin/bash

WATCHYOURLAN_URL="http://localhost:8840"
HEARTBEAT_URL="https://api.vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID"
MAX_STALENESS=120  # 2x the 60-second scan interval = 2 minutes

# Get all hosts and find the most recently seen timestamp
LATEST_SEEN=$(curl -fsS "${WATCHYOURLAN_URL}/api/v1/hosts" | \
  python3 -c "
import json, sys, time
hosts = json.load(sys.stdin)
if not hosts:
    sys.exit(1)
# Find the most recent last_seen across all online hosts
timestamps = [h.get('last_seen', '') for h in hosts if h.get('last_seen')]
if not timestamps:
    sys.exit(1)
# Parse and find the maximum (most recent) timestamp
import datetime
latest = max(timestamps)
print(latest)
")

if [ $? -ne 0 ]; then
  echo "Failed to get host data from WatchYourLAN API"
  exit 1
fi

# Check if the latest seen timestamp is within the acceptable staleness window
# (Implementation depends on timestamp format returned by your WatchYourLAN version)
# If the data is fresh, ping the heartbeat
curl -fsS "$HEARTBEAT_URL"

Add to crontab:

*/3 * * * * /usr/local/bin/watchyourlan-freshness-check.sh

Simpler alternative: If scripting the freshness check is complex, use Vigilmon's keyword monitor on /api/v1/hosts with a MAC address check (Step 3) as the primary scan health signal, and rely on the WatchYourLAN notification system (ntfy, Telegram, etc.) for device-level alerts.

Step 5: Monitor SSL Certificates

WatchYourLAN is typically reverse-proxied via nginx or Caddy when exposed outside localhost or a Docker network. When the certificate expires:

• Homelab dashboards become inaccessible via HTTPS (browser TLS error)
• Remote access to the network monitoring dashboard fails
• Any API consumers using HTTPS fail with TLS errors

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

Caddy users: Caddy handles certificate renewal automatically. Verify Caddy is running and healthy with systemctl status caddy or check the Caddy log for certificate renewal events. Vigilmon's SSL monitor gives you an independent expiry alert even if Caddy's auto-renewal fails.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web dashboard | Non-200 or WatchYourLAN missing | Check process status; inspect container logs if using Docker | | API hosts endpoint | Non-200 or known MAC missing | ARP data issue; check network interface config | | ARP scan freshness heartbeat | Heartbeat missed | Scan loop stalled; check network interface permissions; restart WatchYourLAN | | SSL certificate | < 30 days to expiry | Renew certificate; check reverse proxy config |

Alert after: 2 consecutive failures for HTTP monitors. 1 missed heartbeat for the scan freshness check — a stalled ARP scan means your network visibility is already compromised.

Common WatchYourLAN Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Go process crash / container exit | Web dashboard unreachable; alert within 60 s | | SQLite database file missing or corrupted | Web UI returns error; API returns non-200 | | ARP scan loop stalled (network interface error) | Web UI and API green (stale data); heartbeat missed | | Network interface permission denied | ARP scanning stops; all hosts show stale last_seen | | Docker network configuration change | API returns empty host list; MAC address keyword missing | | Port 8840 firewall block | All HTTP monitors fail | | SSL certificate expires | SSL monitor alerts; remote access fails | | Host machine rebooted, WatchYourLAN not auto-started | All monitors fire simultaneously |

WatchYourLAN's most treacherous failure is the silent scan stall: the application keeps running, the dashboard keeps serving device lists, but the ARP scan loop stopped hours ago. You're looking at a frozen snapshot of your network while new devices may have connected or critical devices may have gone offline. Vigilmon's combination of web UI monitoring, API data validation, and scan freshness heartbeats catches all three failure modes — so you have confidence that your network visibility is real-time, not stale.

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