How to Monitor HashiCorp Boundary with Vigilmon (Zero-Trust Network Access)

HashiCorp Boundary is a zero-trust network access (ZTNA) solution that brokers access to internal services without requiring direct network connectivity. Instead of VPNs or bastion hosts, Boundary issues dynamic credentials and proxies connections through its controllers and workers. When Boundary is unavailable, every engineer loses access to every resource it protects — making it one of the highest-impact services you can run.

In this tutorial you'll set up comprehensive uptime monitoring for Boundary using Vigilmon — free tier, no credit card required.

Why Boundary availability is non-negotiable

Boundary introduces itself as infrastructure-as-an-access-control-plane. This means:

• Controller outage = no credential issuance, no new sessions, no access to any protected resource
• Worker outage = sessions can't be established for the resources served by that worker, even if credentials were issued
• Session broker failure = active connections may break mid-stream during worker restarts

Unlike traditional VPNs that fail loudly, Boundary failures can manifest subtly: connections time out, credentials stop rotating, and engineers waste time debugging their local environment before realizing the platform itself is down. External monitoring catches this immediately.

What you'll need

• A self-hosted Boundary deployment (controller + one or more workers)
• The Boundary controller API reachable on a network-accessible address
• A free Vigilmon account — sign up takes 30 seconds

Understanding Boundary's health endpoints

Boundary exposes health check endpoints on the API listener:

| Endpoint | What it checks | |----------|----------------| | /v1/health | Controller health, database connectivity, worker status | | /health (alias) | Same as above on some versions |

The default API port is 9200 (HTTP or HTTPS depending on your TLS configuration). If you've set tls_disable = true in your controller config for internal use, monitoring is over HTTP. Production deployments should use HTTPS.

A healthy Boundary controller returns a JSON body like:

{
  "status": "ok",
  "active_session_count": 12
}

Step 1: Verify the health endpoint

Before adding Vigilmon monitors, confirm Boundary is responding:

# For HTTPS deployments
curl -s https://boundary.example.com:9200/v1/health | jq .

# For HTTP-only internal deployments (not recommended for production)
curl -s http://boundary-controller.internal:9200/v1/health | jq .

# Expected output:
# {
#   "status": "ok",
#   "active_session_count": 5
# }

If the endpoint returns a non-200 status or connection is refused, check that:

• The Boundary controller is running (systemctl status boundary)
• The API listener address in your Boundary config matches where you're connecting
• Your firewall allows access to port 9200 from monitoring probe IPs

Step 2: Monitor the Boundary controller health

The controller health endpoint is your primary external signal for Boundary availability.

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to: https://boundary.example.com:9200/v1/health
4. Set check interval to 1 minute
5. Under Expected response:
   • Status code: 200
   • Response body contains: "ok" (matches the healthy status)
6. Save the monitor

This monitor fires if:

• The Boundary controller process crashes
• The database connection fails (Boundary returns non-200 if it can't reach PostgreSQL)
• TLS certificate issues prevent connections

Step 3: Monitor worker connectivity

Boundary workers connect back to controllers via an upstream address. You can verify worker-to-controller connectivity is intact by checking the health endpoint — it reflects worker registration state in some versions.

For more direct worker health validation, add a TCP monitor for the worker's proxy listener (default port 9202):

1. Create a new TCP Port monitor
2. Host: boundary-worker.example.com
3. Port: 9202
4. Check interval: 1 minute
5. Save

Port 9202 is the worker's data plane port — what clients connect through to reach proxied resources. If this port is unreachable, no sessions can be established through that worker.

If you run multiple workers across availability zones or regions, add a TCP monitor for each worker's port 9202. A healthy controller with a dead worker silently degrades your access capacity.

Step 4: Monitor the API listener TCP port

Independent TCP monitoring of the API port gives you a signal that doesn't depend on the application layer responding correctly:

1. Create a new TCP Port monitor
2. Host: boundary.example.com
3. Port: 9200
4. Check interval: 1 minute
5. Save

This catches scenarios where the controller process is alive but the HTTP handler has hung — the TCP port answers but HTTP requests time out. You'll see the TCP monitor pass but the HTTP monitor fail, giving you a clear signal to look at the controller process state rather than the network.

Step 5: Monitor the session broker endpoint

If you expose the Boundary UI (the web interface for managing resources and sessions), add an HTTP monitor for it as well. The Boundary UI typically runs on port 9200 (same listener as the API) but you can add an additional monitor for the UI root:

1. Create a new HTTP / HTTPS monitor
2. URL: https://boundary.example.com:9200/
3. Expected status code: 200 (the UI returns a redirect or the React app shell)
4. Save

For organizations where engineers access Boundary through the desktop client (Boundary Desktop), the API endpoint monitor above covers their access path. The UI monitor is primarily for self-service and administrative access.

Step 6: Configure alert channels

Boundary outages affect every engineer accessing protected infrastructure. Route alerts to your highest-visibility channels.

Email alerts

1. Go to Alert Channels → Add Channel → Email
2. Enter your on-call or platform team email
3. Assign to all Boundary monitors

Webhook alerts (Slack, PagerDuty)

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your Slack webhook or PagerDuty endpoint
3. Assign to all Boundary monitors

A recommended Slack message structure when a Boundary alert fires:

{
  "monitor_name": "Boundary Controller /v1/health",
  "status": "down",
  "url": "https://boundary.example.com:9200/v1/health",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 90
}

Pin your Boundary runbook link in the Slack channel so engineers can jump directly to the triage steps.

Step 7: Diagnosing Boundary alerts

When Vigilmon fires a Boundary alert, follow this triage sequence:

# 1. Check if the controller is running
systemctl status boundary

# 2. Check controller logs for database errors
journalctl -u boundary -n 50 --no-pager | grep -E "error|fatal|database"

# 3. Verify PostgreSQL connectivity from the controller
psql "$BOUNDARY_DB_URL" -c "SELECT 1"

# 4. Check worker status (from the controller)
boundary workers list -token=file:///path/to/token

# 5. Test the health endpoint directly
curl -v https://boundary.example.com:9200/v1/health

# 6. Check worker logs (on the worker host)
journalctl -u boundary-worker -n 50 --no-pager

Common root causes:

• PostgreSQL connection pool exhaustion — Boundary can't serve requests if it can't reach its database
• Worker upstream disconnect — network partition between worker and controller
• KMS/vault connectivity failure — if you use Vault as Boundary's key management service, a Vault outage prevents Boundary from decrypting credentials

Recommended monitor set for Boundary

| Monitor | Type | Alert Priority | |---------|------|----------------| | https://boundary.example.com:9200/v1/health | HTTP | Critical | | boundary.example.com:9200 | TCP | High | | boundary-worker-1.example.com:9202 | TCP | High | | boundary-worker-2.example.com:9202 | TCP | High | | TLS cert expiry (via HTTPS monitors) | SSL | Warning (14 days) |

Add one TCP worker monitor per worker in your fleet. Workers are independent, so a silent worker failure reduces your session capacity without triggering a controller health alert.

What's next

• Heartbeat monitoring — if you use Boundary for CI/CD access (running boundary connect in pipelines), add a heartbeat monitor to confirm pipelines are still successfully establishing sessions
• Status page — create an internal status page for your platform engineering team that combines your Boundary monitors with your other infrastructure access tools
• Database monitoring — since Boundary is tightly coupled to PostgreSQL, add PostgreSQL monitoring alongside your Boundary monitors

Get started free at vigilmon.online — no credit card, monitors running in under a minute.