How to Monitor CapRover with Vigilmon (Dashboard, TCP, and SSL Alerts)

CapRover is an open-source self-hosted PaaS — a Heroku-style platform that lets you deploy apps with a single command. When CapRover itself goes down, every application running on it becomes undeployable, and your deployment pipeline grinds to a halt.

This tutorial shows you how to set up external monitoring for CapRover using Vigilmon so you know the moment anything goes wrong — free tier, no credit card.

Why CapRover needs its own monitoring

CapRover manages your apps, but nothing is managing CapRover. Common failure modes:

• Dashboard unavailable — the CapRover web UI returns an error; you can't deploy, scale, or configure apps
• Captain (backend) crash — the captain service restarts or crashes; API calls from the CLI (caprover deploy) start failing
• Worker port unreachable — CapRover uses port 3000 internally and port 80/443 for apps; a port binding failure blocks all traffic
• SSL certificate expires — Let's Encrypt auto-renewal fails silently; your *.your-domain.com wildcard cert lapses and all apps break at once

External monitoring gives you early warning before your developers hit errors mid-deployment.

What you'll need

• A running CapRover instance (single-node or cluster)
• A free Vigilmon account

Step 1: Locate your CapRover health endpoint

CapRover exposes a health check at the root of its API. Verify it from your terminal:

curl https://captain.yourdomain.com/api/v2/user/system/info \
  -H "x-namespace: captain" \
  -H "x-captain-auth: your-password"
# Expect: {"status":100,"description":"OK",...}

For a simpler unauthenticated liveness check, the dashboard itself returns 200 when the service is healthy:

curl -I https://captain.yourdomain.com
# Expect: HTTP 200 or 302 (redirect to login page)

Either URL works for basic availability monitoring. The unauthenticated dashboard URL is simplest for Vigilmon.

Step 2: Monitor the CapRover dashboard

The dashboard is the primary interface for your team. If it goes down, no one can deploy or manage apps.

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. URL: https://captain.yourdomain.com
4. Check interval: 1 minute
5. Expected status code: 200 (or 302 if CapRover redirects to a login page)
6. Save the monitor

This catches: CapRover container crashes, Docker network failures, nginx proxy errors upstream of Captain.

Step 3: Add a TCP port check for the worker port

CapRover routes all app traffic through its NGINX proxy layer. A TCP check on port 80 and 443 confirms that the proxy is accepting connections — separate from whether the dashboard is responsive.

1. Monitors → New Monitor → TCP Port
2. Host: yourdomain.com (your CapRover root domain)
3. Port: 80
4. Save the monitor

Repeat for port 443. These checks fire even if the HTTP-level response is healthy but the underlying socket is refusing connections — a scenario that can happen when NGINX restarts during config regeneration.

Step 4: Monitor SSL certificate expiry

CapRover manages Let's Encrypt certificates for all your apps via its wildcard cert. When that cert expires, every app on *.yourdomain.com breaks simultaneously.

1. Monitors → New Monitor → SSL Certificate
2. Domain: captain.yourdomain.com
3. Alert when expiring in fewer than: 14 days
4. Save the monitor

Also add a check for yourdomain.com if you serve apps on the root domain. A 14-day window gives you two weeks to trigger a manual renewal if the automatic Let's Encrypt renewal fails.

Step 5: Set up alert channels

1. Alert Channels → Add Channel
2. Choose Slack, email, Discord, or webhook
3. Assign the channel to all your CapRover monitors

For a DevOps team, routing CapRover alerts to a dedicated #platform-alerts Slack channel (separate from app-level alerts) keeps the signal clean. When CapRover goes down, a single notification explains why every downstream app deployment is failing.

Sample alert:

[DOWN] CapRover Dashboard
https://captain.yourdomain.com
Status: Connection refused
Down for: 2 minutes

Step 6: Monitor individual apps deployed on CapRover

CapRover availability and app availability are independent. A healthy CapRover can still serve a broken app container. Add HTTP monitors for each critical application:

1. Create a new HTTP monitor for each app: https://myapp.yourdomain.com/health
2. Group monitors by tagging them (e.g., platform for CapRover infra, apps for deployed workloads)

This two-layer view — platform health vs. app health — lets you immediately distinguish "CapRover itself is down" from "one app is broken."

Monitoring summary

| Monitor | Type | What it catches | |---------|------|-----------------| | https://captain.yourdomain.com | HTTP | Dashboard down, Captain crash, proxy failure | | yourdomain.com:80 | TCP | Port 80 unreachable, NGINX not accepting connections | | yourdomain.com:443 | TCP | Port 443 unreachable, TLS termination failure | | captain.yourdomain.com | SSL | Wildcard cert expiry before all apps break |

What's next

• Heartbeat monitoring — CapRover cron jobs and deploy pipelines can report into Vigilmon heartbeats so you know when a scheduled deploy stops running
• Response time history — track dashboard load time over time to catch memory pressure on your CapRover host before it becomes downtime

Get started free at vigilmon.online — no credit card, monitors up in under two minutes.