Monitoring Uptime Kuma with Vigilmon

Uptime Kuma is the most popular open-source self-hosted uptime monitoring alternative, built on Node.js with a WebSocket-based real-time dashboard and Docker-friendly deployment. It's beautiful, capable, and trusted by thousands of self-hosters to watch their services. But Uptime Kuma has a blind spot: it cannot monitor itself. If the Node.js process crashes, the Docker container exits, or the reverse proxy goes down, Uptime Kuma goes silent — and so do all its alerts. Vigilmon solves this with meta-monitoring: watching Uptime Kuma's web UI, health API endpoint, WebSocket availability, and SSL certificates so your uptime monitor stays up.

What You'll Set Up

• HTTP uptime monitor for the Uptime Kuma web UI (default port 3001)
• Health endpoint check via /api/entry-page
• SSL certificate expiry alerts for HTTPS-proxied Uptime Kuma setups
• Cron heartbeat for Uptime Kuma's own monitoring service availability (meta-monitoring)

Prerequisites

• Uptime Kuma 1.23+ running via Docker or Node.js directly
• Web UI accessible at http://your-server:3001 or via a reverse proxy
• A free Vigilmon account

Step 1: Monitor the Uptime Kuma Web UI

The Uptime Kuma dashboard is the primary availability signal. If Node.js crashes or the container exits, this URL stops responding.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your Uptime Kuma URL:
   • Direct: http://your-server-ip:3001
   • Reverse proxied: https://uptime.yourdomain.com
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

Add a keyword check to confirm Uptime Kuma is responding, not just the reverse proxy:

1. Open the monitor settings.
2. Enable Keyword check.
3. Enter Uptime Kuma as the expected keyword — it appears in the page title of the dashboard.
4. Click Save.

This distinguishes an Uptime Kuma application failure from a case where nginx returns 502 Bad Gateway (which would also fail the HTTP status check).

Step 2: Check the /api/entry-page Health Endpoint

Uptime Kuma exposes /api/entry-page, which returns the application's initial configuration data as JSON. This endpoint is lightweight, requires no authentication, and confirms the Node.js application layer is healthy — not just that a reverse proxy is serving cached responses.

1. In Vigilmon, click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: https://uptime.yourdomain.com/api/entry-page (or http://your-server-ip:3001/api/entry-page).
4. Set Expected HTTP status to 200.
5. Enable Keyword check with expected value "type": — this confirms the JSON response contains application data.
6. Set Check interval to 1 minute.
7. Click Save.

Verify the endpoint manually:

curl -s http://localhost:3001/api/entry-page | python3 -m json.tool | head -10
# Should return JSON with {"type": ..., "title": ...}

If this endpoint returns an error while the web UI appears healthy, it often indicates a database corruption issue or Node.js startup error.

Step 3: Verify WebSocket Signaling Availability

Uptime Kuma's real-time dashboard relies on WebSocket connections (Socket.IO) to push live status updates to connected browsers. A WebSocket failure means the dashboard loads but shows stale data — monitors appear frozen at their last known state.

Test WebSocket connectivity from the server:

# Install wscat if not available
npm install -g wscat

# Test WebSocket handshake (Uptime Kuma uses Socket.IO)
curl -s "http://localhost:3001/socket.io/?EIO=4&transport=polling" | head -c 100
# Should return data starting with 0{"sid":...

Add a Vigilmon monitor for the Socket.IO polling endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://uptime.yourdomain.com/socket.io/?EIO=4&transport=polling.
3. Set Expected HTTP status to 200.
4. Enable Keyword check with expected value "sid": — confirms Socket.IO handshake data is returned.
5. Set Check interval to 5 minutes.
6. Click Save.

This catches scenarios where the HTTP server responds but Socket.IO has crashed internally, which would leave browser dashboards showing outdated monitor states.

Step 4: SSL Certificate Alerts for HTTPS Uptime Kuma

Uptime Kuma itself monitors SSL certificates for the services it watches, but it cannot watch its own certificate. If you front Uptime Kuma with nginx or Caddy and the TLS certificate expires, the dashboard becomes inaccessible and all WebSocket-based alerts stop flowing.

1. Open the HTTP monitor from Step 1.
2. Enable Monitor SSL certificate under the SSL section.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

For nginx reverse proxy setups, verify your certificate setup:

# Check Let's Encrypt certificate for your Uptime Kuma domain
certbot certificates --domain uptime.yourdomain.com

# Verify nginx SSL config
nginx -T 2>&1 | grep -A3 "server_name.*uptime"

For Caddy, which handles certificates automatically:

# Check Caddy certificate storage
ls ~/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/

# View Caddy logs for renewal activity
journalctl -u caddy --since "7 days ago" | grep -i "certificate\|renew\|tls"

Step 5: Heartbeat Monitoring for Uptime Kuma's Service Availability

The deepest form of Uptime Kuma meta-monitoring is to have Uptime Kuma ping Vigilmon periodically, confirming that its own monitoring engine is running and processing checks — not just that the web UI is accessible.

Uptime Kuma has built-in support for push monitors. Configure a push monitor inside Uptime Kuma to ping Vigilmon:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to 1 minute.
3. Set Grace period to 2 minutes.
4. Copy the heartbeat URL: https://vigilmon.online/heartbeat/abc123.

Inside Uptime Kuma, create a monitor that pings this URL:

1. Click Add New Monitor.
2. Set Monitor Type to HTTP(s).
3. Enter URL: https://vigilmon.online/heartbeat/abc123.
4. Set Heartbeat Interval to 60 seconds.
5. Set the Monitor Name to Vigilmon Heartbeat Ping.
6. Click Save.

Now Uptime Kuma sends a ping to Vigilmon every minute. If Uptime Kuma's monitoring engine stops processing (even while the web UI is still up), these pings stop and Vigilmon alerts you. This is true meta-monitoring: each service watches the other.

For Docker deployments, also add a container health check to catch silent container restarts:

# docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/api/entry-page"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

This gives Docker's own scheduler visibility into Uptime Kuma health for auto-restart logic.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add email, Slack, or a webhook.
2. Set Consecutive failures before alert to 2 on the web UI monitor — Node.js startup after a container restart typically takes 5–10 seconds and may cause one check to fail.
3. Set Consecutive failures before alert to 1 on the heartbeat monitor — a missed heartbeat from Uptime Kuma's engine means your other monitoring is already blind.
4. Use Maintenance windows during Uptime Kuma upgrades:

# Before upgrading (Docker example)
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "abc123", "duration_minutes": 10}'

# Pull new image and restart
docker pull louislam/uptime-kuma:latest
docker compose up -d

# Maintenance window expires automatically

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web UI | Port 3001 or reverse proxy | Node.js crash, container exit | | Health API | /api/entry-page | Application layer failure, DB error | | WebSocket polling | /socket.io/ endpoint | Socket.IO crash, stale dashboard | | SSL certificate | HTTPS reverse proxy domain | Certificate expiry, renewal failure | | Engine heartbeat | Vigilmon heartbeat URL | Monitoring engine stopped processing |

Uptime Kuma is built to tell you when things go down — but it can't tell you when it goes down. With Vigilmon watching Uptime Kuma's web UI, health API, WebSocket layer, and monitoring engine heartbeat, you close the loop: your uptime monitor is monitored, and your alerting pipeline stays reliable even when a single node fails.