How to Monitor Teleport with Vigilmon (Zero-Trust Access Platform)

Teleport is the backbone of zero-trust access for many self-hosted infrastructure teams — it proxies SSH, Kubernetes, databases, and web apps through a single secure gateway, replacing VPN-based access with short-lived certificates and audit logs. When Teleport goes down, engineers lose access to every protected resource at once. That's why external monitoring isn't optional for Teleport deployments.

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

Why monitoring Teleport is critical

Teleport is a multiplexer for access. A single Auth Server or Proxy Service failure ripples across every team and every tool that relies on it:

SSH access breaks — engineers can't log into production servers
Kubernetes access breaks — kubectl commands fail with authentication errors
Database proxying breaks — database clients can't connect through the Teleport database service
Certificate issuance stops — even if users have active sessions, cert renewal fails when the Auth Server is unreachable
Web app access breaks — any app proxied through the Application Service becomes unavailable

Because Teleport serves as an access control plane rather than just a single service, the blast radius of an outage is disproportionately large. Detecting it within seconds — rather than waiting for an engineer to notice they can't ssh into something — is essential.

What you'll need

A running Teleport cluster (self-hosted, any version 10+)
The Teleport Proxy Service reachable on a public or monitoring-accessible hostname
A free Vigilmon account — sign up takes 30 seconds

Understanding Teleport's health endpoints

Teleport exposes several HTTP endpoints you can monitor:

| Endpoint | Port | What it checks | |----------|------|----------------| | /web/ping | 443 (proxy) | Proxy Service is alive and reachable | | /healthz | 3025 (auth) | Auth Server health (if directly accessible) | | /readyz | 3025 (auth) | Auth Server is ready to serve requests | | /v1/webapi/ping | 443 (proxy) | Auth API through the proxy — verifies the full stack |

The most important endpoint to monitor externally is /web/ping on your proxy's public address. This returns 200 OK when the proxy is up and confirms it can reach the Auth Server.

Step 1: Verify your health endpoints

Before adding monitors, confirm the endpoints are responding:

# Replace teleport.example.com with your Teleport proxy hostname
curl -s https://teleport.example.com/web/ping | jq .

# Expected output:
# {
#   "server_version": "14.1.3",
#   "min_client_version": "12.0.0",
#   "cluster_name": "example.com",
#   "proxy_public_addr": "teleport.example.com:443"
# }

If you have direct access to the Auth Server (common in self-hosted setups):

# Auth Server health on its internal port
curl -k https://auth.internal:3025/healthz
# Returns: OK

curl -k https://auth.internal:3025/readyz
# Returns: OK (or 503 if not yet ready)

Step 2: Monitor the Proxy Service

The Teleport Proxy is your external-facing component and the most critical service to monitor.

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the type
Set the URL to: https://teleport.example.com/web/ping
Set check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: "server_version" (confirms JSON payload from a live server)
Save the monitor

This monitor confirms that:

Your Teleport proxy's TLS certificate is valid
The proxy process is accepting connections
The proxy can communicate with the Auth Server (it reads version info from auth)

Step 3: Monitor the Auth API through the proxy

The /v1/webapi/ping endpoint exercises the full request path from the outside world through the proxy to the Auth Server. Add a second monitor for this:

Create a new HTTP / HTTPS monitor
URL: https://teleport.example.com/v1/webapi/ping
Check interval: 1 minute
Expected status code: 200
Response contains: "cluster_name" (confirms auth is responding)

Having both /web/ping and /v1/webapi/ping gives you independent signal: if /web/ping passes but /v1/webapi/ping fails, the proxy is up but there's a fault between the proxy and the Auth Server.

Step 4: Monitor the SSH gateway TCP port

Teleport's SSH service multiplexes traffic on port 3022 (node service) and the proxy SSH port (typically 3023 or 443 with multiplexing). TCP monitoring confirms the port is open and accepting connections even before HTTP-level validation:

Go to Monitors → New Monitor
Choose TCP Port
Host: teleport.example.com
Port: 443 (standard TLS multiplexing) or 3023 if you use a dedicated SSH proxy port
Check interval: 1 minute
Save

If the TCP monitor fails while the HTTP monitor is passing, you likely have a routing or firewall issue specific to the SSH path.

Step 5: Monitor the Kubernetes gateway

If you use Teleport as a Kubernetes proxy, it typically listens on port 3026 for the Kubernetes API. Add a TCP monitor for this port:

New TCP Port monitor
Host: teleport.example.com
Port: 3026
Check interval: 1 minute
Save

A failure here means engineers can't run kubectl commands through Teleport, even if SSH access still works.

Step 6: Monitor TLS certificate expiry

Teleport uses short-lived certificates internally, but the proxy's external TLS certificate (typically a Let's Encrypt cert) can still lapse if auto-renewal breaks. Vigilmon monitors TLS certificate expiry automatically on any HTTPS monitor.

To verify the certificate alert is enabled:

Open your /web/ping monitor settings
Confirm SSL certificate alerts are enabled (this is on by default for HTTPS monitors)
Set the warning threshold to 14 days before expiry — gives you time to act before Teleport clients start rejecting the certificate

If cert-manager or Teleport's built-in certificate management stops renewing the proxy cert, you'll get an alert 14 days before the cert expires.

Step 7: Configure alert channels

When Teleport goes down, every engineer who relies on it needs to know immediately.

Email alerts

Go to Alert Channels → Add Channel → Email
Add your on-call or infrastructure team email
Assign to all Teleport monitors

Webhook alerts (Slack, PagerDuty, etc.)

Go to Alert Channels → Add Channel → Webhook
Enter your Slack incoming webhook URL or PagerDuty integration endpoint
Assign to all Teleport monitors

Example alert payload:

{
  "monitor_name": "Teleport Proxy /web/ping",
  "status": "down",
  "url": "https://teleport.example.com/web/ping",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 45
}

Route Teleport alerts to your highest-priority channel — an alert here means your entire team has lost infrastructure access.

Step 8: Diagnosing Teleport alerts

When you receive a Vigilmon alert for Teleport, use this triage runbook:

# 1. Check if the proxy process is running
systemctl status teleport

# 2. Check Teleport service health
tctl status

# 3. Check auth server connectivity from the proxy
tctl --auth-server=auth.internal:3025 status

# 4. Review recent Teleport logs
journalctl -u teleport -n 100 --no-pager

# 5. Check certificate validity
echo | openssl s_client -connect teleport.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# 6. Check backend connectivity (etcd, DynamoDB, etc.)
# Varies by backend — check your Teleport configuration

Recommended monitor set for Teleport

| Monitor | Type | Alert Priority | |---------|------|----------------| | https://teleport.example.com/web/ping | HTTP | Critical | | https://teleport.example.com/v1/webapi/ping | HTTP | Critical | | teleport.example.com:443 | TCP | High | | teleport.example.com:3026 | TCP | High (if using K8s proxy) | | TLS cert expiry (via HTTPS monitors) | SSL | Warning (14 days) |

What's next

Heartbeat monitoring — if you run Teleport with Machine ID (bot certificates for CI/CD), add a heartbeat monitor to confirm your bots are still renewing certs successfully
Status page — publish a Teleport status page for your engineering team so they have a canonical reference during incidents rather than filing tickets
Multi-cluster monitoring — if you run a root cluster with leaf clusters, add monitors for each leaf cluster's proxy endpoint

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