Monitoring AdGuard Home with Vigilmon

AdGuard Home is a powerful self-hosted DNS server and network-wide blocker, but like any self-hosted service it can fail quietly. The Go daemon can crash, port 3000 can become unreachable after a kernel update, or a misconfigured upstream can silently forward all queries unfiltered. Vigilmon lets you watch AdGuard Home from the outside — web UI, control API, DNS health, and SSL certificates — so failures surface in seconds, not hours.

What You'll Set Up

• HTTP monitor for the AdGuard Home web interface
• /control/status API endpoint health check
• DNS query response monitoring via API stats
• SSL certificate expiry alerts
• Alert channels for immediate notification

Prerequisites

• AdGuard Home v0.107+ running on a Linux/macOS host or Raspberry Pi
• Web UI reachable at http://<host>:3000 (or your custom port/domain)
• A free Vigilmon account

Step 1: Monitor the Web Interface

AdGuard Home's web dashboard runs on port 3000 by default. A simple HTTP check confirms the frontend is up and the Go process is listening.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: http://<your-adguard-ip>:3000 (e.g. http://192.168.1.3:3000).
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200.
6. Click Save.

If the AdGuard Home process crashes or the port closes, this monitor alerts immediately.

Step 2: Poll the /control/status API

AdGuard Home exposes a REST API that returns detailed service state. The /control/status endpoint is the most useful health signal — it tells you whether filtering is enabled and whether DNS is running.

http://<your-adguard-ip>:3000/control/status

A healthy response looks like:

{
  "dns_addresses": ["192.168.1.3"],
  "dns_port": 53,
  "http_port": 3000,
  "protection_enabled": true,
  "running": true,
  "version": "v0.107.50"
}

Configure Vigilmon to assert on running:

1. Add Monitor → HTTP / HTTPS.
2. URL: http://<your-adguard-ip>:3000/control/status.
3. Set Expected body contains to "running":true.
4. Set Check interval to 2 minutes.
5. Click Save.

This detects the case where the web server responds but AdGuard Home's internal DNS service has stopped — a subtle failure mode the web UI check alone would miss.

Step 3: Verify DNS Filtering Is Active

Beyond the status check, you want to confirm that filtering is actually enabled — not just that the daemon is running. The /control/status response includes "protection_enabled":true when network-wide blocking is on.

Update your Step 2 monitor (or add a second one) with:

• Expected body contains: "protection_enabled":true

If someone disables filtering via the UI (accidentally or deliberately) or a failed update toggles it off, Vigilmon alerts you.

For deeper DNS health validation, use the /control/stats endpoint:

http://<your-adguard-ip>:3000/control/stats

This returns query counts over the last 24 hours. A num_dns_queries value of 0 after several hours of expected traffic signals that DNS has stopped flowing — useful for catching silent upstream resolver failures.

Step 4: SSL Certificate Monitoring

If you've placed AdGuard Home behind a reverse proxy (nginx, Caddy, Traefik) with a TLS certificate, add a certificate expiry monitor:

1. Add Monitor → SSL Certificate.
2. Enter your domain: https://adguard.home.yourdomain.com.
3. Set Alert when certificate expires in less than 30 days.
4. Click Save.

AdGuard Home also supports native TLS configuration (set in AdGuardHome.yaml). If you use this, monitor the same domain — an expired cert silently breaks HTTPS access to the control API and web UI.

Step 5: Monitor the DNS Port Directly

The web API and UI checks confirm the HTTP layer, but you can also watch port 53 directly with a Vigilmon TCP monitor:

1. Add Monitor → TCP Port.
2. Host: <your-adguard-ip>, Port: 53.
3. Set Check interval to 2 minutes.
4. Click Save.

A TCP check on port 53 fails if the DNS listener is down even when the web UI is still reachable — for example, if another process has taken port 53 after a reboot and AdGuard Home failed to rebind.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add your preferred channel: email, Slack, PagerDuty, or a custom webhook.
2. For the /control/status monitor, set Consecutive failures before alert to 2 — AdGuard Home restarts within seconds after most crashes, so a single probe failure may be a false alarm.
3. Add a Maintenance window for your update schedule (AdGuardHome --update takes the service offline for ~10 seconds).

Going Further

• Parental controls verification: The /control/filtering/status endpoint returns whether DNS filtering rules are loaded. Monitor it to confirm blocklists haven't been cleared after an update.
• Multiple upstream DNS: If you've configured fallback upstream resolvers, the /control/stats response will show their usage — a spike in fallback queries can indicate your primary upstream is failing.
• Raspberry Pi pairing: Combine this monitoring setup with a Pi-hole backup (monitored separately) for full DNS redundancy with visibility into both.

With Vigilmon watching AdGuard Home's control API, DNS port, and SSL certificate, you'll know the moment your network-wide blocker goes dark — before unfiltered ads and tracking pixels start flowing to every device in the house.