tutorial

Monitoring Pritunl with Vigilmon

Pritunl is a distributed OpenVPN server with a web console, API, and authentication portal. Learn how to monitor every layer — web UI, VPN endpoints, API health, and user portal — with Vigilmon.

Pritunl is one of the most capable self-hosted VPN solutions available — a distributed OpenVPN and WireGuard server with a polished web console, multi-server clustering, and a user authentication portal. But when Pritunl goes down, it doesn't just break remote access — it locks out every remote team member, blocks access to internal services, and silently drops active VPN tunnels. Vigilmon gives you external visibility into every layer of Pritunl before your team starts filing helpdesk tickets.

What You'll Set Up

  • HTTP monitor for the Pritunl web console
  • VPN endpoint reachability check (TCP/UDP port)
  • API health check against the Pritunl REST API
  • User authentication portal availability
  • Alert channels for immediate notification

Prerequisites

  • Pritunl v1.30+ running on a Linux host
  • Web console reachable at https://<host> (port 443 by default)
  • Admin API key and secret (generated in Pritunl settings)
  • A free Vigilmon account

Step 1: Monitor the Web Console

The Pritunl web console is the control plane for all VPN configuration. If this goes down, administrators lose the ability to manage servers, users, and routes. Pritunl's embedded nginx serves the console on port 443 by default — a simple HTTPS check confirms the frontend is alive.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the URL: https://<your-pritunl-host> (e.g. https://vpn.example.com).
  4. Set Check interval to 2 minutes.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Pritunl's web console returns a 200 with a React SPA when the service is healthy. A 502, 503, or connection timeout indicates either the Pritunl service has crashed or the embedded nginx process has stopped.

Step 2: Monitor VPN Endpoint Reachability

The VPN endpoint is what your clients actually connect to. Pritunl runs OpenVPN on a configurable port — commonly UDP 1194 for OpenVPN or TCP 443 for TCP-mode tunnels. Vigilmon's TCP port monitor can confirm the endpoint is open even when the web console is unreachable.

For TCP-mode VPN servers:

  1. Add Monitor → TCP Port.
  2. Host: <your-pritunl-host>, Port: 1194 (or your configured port).
  3. Set Check interval to 2 minutes.
  4. Click Save.

For servers where you want to verify the OpenVPN handshake port is accepting connections:

  • If running TCP mode: use TCP port 443 or your custom port.
  • If running UDP mode: use a TCP port check against the management port instead (commonly 7505).

This check catches the most dangerous failure mode: the web console loads fine (Pritunl's HTTP layer is up) but the OpenVPN process has crashed and tunnels are silently dropping.

Step 3: Health-Check the Pritunl REST API

Pritunl exposes a REST API that powers the web console. You can query it directly to confirm the service is not just listening but actually processing requests. The /ping endpoint is the lightest health signal.

GET https://<your-pritunl-host>/ping

A healthy response returns:

{"ping": "pong"}

Configure Vigilmon to assert on this response:

  1. Add Monitor → HTTP / HTTPS.
  2. URL: https://<your-pritunl-host>/ping.
  3. Set Expected body contains to pong.
  4. Set Check interval to 2 minutes.
  5. Click Save.

For deeper API validation using your admin credentials, you can also poll /server — Pritunl's server list endpoint — with HTTP Basic Auth using your API key and secret. This confirms the database connection and server state are intact, not just the HTTP layer.

GET https://<host>/server
Authorization: Basic <base64(api-key:api-secret)>

A successful response returns your list of configured VPN servers with their current status fields (online, offline, disconnected). If any server shows offline unexpectedly, that is a signal worth alerting on.

Step 4: Monitor the User Authentication Portal

Pritunl includes a user-facing authentication portal — typically at https://<host>/user — where end users log in to download VPN profiles and manage their credentials. When this breaks, users can't onboard or rotate their credentials.

  1. Add Monitor → HTTP / HTTPS.
  2. URL: https://<your-pritunl-host>/user.
  3. Set Expected HTTP status to 200.
  4. Set Expected body contains to Pritunl (or another string from the login page title).
  5. Set Check interval to 5 minutes.
  6. Click Save.

The user portal runs on the same embedded nginx as the main console, so a failure here often coincides with Step 1 — but the separate check catches application-level routing failures where the console is up but the /user path errors.

Step 5: Monitor SSL Certificate Expiry

Pritunl's web console and API are served over HTTPS with a certificate you manage. An expired certificate breaks the console for administrators and blocks client reconnects that validate the server cert.

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

Pritunl uses Let's Encrypt auto-renewal by default when configured. Vigilmon's SSL monitor catches cases where auto-renewal failed silently — a common issue when port 80 is firewalled or the certbot cron job has drifted.

Step 6: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add your channel: email, Slack, PagerDuty, or a custom webhook.
  2. For the VPN endpoint monitor, set Consecutive failures before alert to 1 — a single missed check on a VPN port is serious enough to page immediately.
  3. For the web console and API monitors, use 2 consecutive failures to avoid alerting on momentary Pritunl service restarts (which take 5–15 seconds during configuration changes).
  4. Add a Maintenance window during scheduled Pritunl upgrades so you don't receive false-positive alerts.

Consider a dedicated high-urgency alert channel for the VPN endpoint check and a lower-urgency channel for the web console — users care about tunnel availability, not admin console uptime.

Step 7: Cluster and Multi-Server Monitoring

If you run a Pritunl cluster with multiple hosts, each server node needs its own set of monitors. The Pritunl API exposes per-server status at /server/<server-id> — poll each node independently so a single-node failure surfaces in your monitoring before it degrades client connections.

For high-availability clusters:

  • Monitor the load balancer VIP (or DNS round-robin endpoint) for the VPN port.
  • Monitor each individual Pritunl node's web console separately.
  • Alert on any node going offline even if the cluster is redundant — a degraded cluster is a future outage.

Going Further

  • Authentication events: The Pritunl API exposes /log entries that surface authentication failures. Set up a periodic monitor or webhook integration to alert on spikes in failed auth attempts.
  • Connected users: Poll /server/<server-id>/output to monitor VPN server logs — a useful signal for unexpected disconnects or tunnel errors.
  • MongoDB health: Pritunl stores all state in MongoDB. If your MongoDB instance is co-hosted, add a TCP port check on 27017 to catch database layer failures before they corrupt Pritunl state.

With Vigilmon watching the Pritunl web console, VPN endpoints, REST API, and user portal, your team gets alerted the moment remote access infrastructure degrades — not when the first employee calls to say they can't connect.

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