How to Monitor Spacebar (Self-Hosted Discord) with Vigilmon

Spacebar is an open source, self-hosted server that implements the Discord client protocol — the same WebSocket gateway, REST API, and CDN interface that the official Discord desktop and mobile apps speak. Teams and communities running Spacebar get Discord's familiar UX (servers, channels, roles, voice, bots, webhooks) while keeping all user data on their own infrastructure, avoiding Discord's Terms of Service restrictions, and maintaining full data sovereignty.

But self-hosting a Discord-compatible backend means owning its availability. When the Spacebar HTTP API goes down, users can't log in. When the WebSocket gateway crashes, all connected clients disconnect simultaneously. When the CDN becomes unavailable, image uploads and attachments fail. None of these failures notify you proactively — unless you have external monitoring in place.

This tutorial shows you how to set up Vigilmon monitoring for Spacebar's HTTP API, WebSocket gateway, CDN, and database layer so you know about failures in seconds rather than hearing about them from your users.

Why Spacebar needs external monitoring

Spacebar is a multi-service application. Each component can fail independently:

HTTP API down — users can't log in, send messages, update settings, or perform any REST operations; Discord clients show "connecting…" indefinitely
WebSocket gateway crash — all connected clients lose their real-time session simultaneously; clients will attempt to reconnect, creating a reconnection storm
Database connectivity loss — API returns 500 errors on most operations; new messages aren't persisted; the service appears up but is functionally broken
CDN unavailable — file uploads fail silently; existing attachments and avatars return 404; the chat interface works but appears broken to users
Voice server crash — users in voice channels are dropped; no automatic recovery until the MediaSoup process is restarted manually

Spacebar's own process health checks only tell you if the Node.js process is running. They don't tell you if clients can actually connect, if the database is responding, or if voice infrastructure is functional. External monitoring closes this gap.

What you'll need

A running Spacebar instance (self-hosted, any deployment method: Docker, bare metal, Kubernetes)
Spacebar's HTTP API, WebSocket, and CDN endpoints accessible from the internet (or your monitoring network)
A free Vigilmon account

Step 1: Verify your Spacebar endpoints

Spacebar runs on several ports by default. Confirm your endpoints before adding monitors:

# HTTP API — default port 3001
curl http://your-spacebar-host:3001/api/ping
# {"ping":"pong"}

# CDN — default port 3003
curl http://your-spacebar-host:3003/
# (should return 200 or a CDN index response)

# Check active WebSocket connections (from server)
ss -s | grep ESTABLISHED

If you're running Spacebar behind a reverse proxy (nginx, Caddy), use your domain instead:

curl https://spacebar.yourdomain.com/api/ping

Note your endpoints:

HTTP API: https://spacebar.yourdomain.com/api/ping (or http://host:3001/api/ping)
CDN: https://cdn.yourdomain.com/ (or http://host:3003/)

Step 2: Add the Spacebar API health monitor

The /api/ping endpoint is Spacebar's built-in health probe. Monitor it first:

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to https://spacebar.yourdomain.com/api/ping
Set the check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: pong
Name the monitor: Spacebar HTTP API
Save the monitor

Vigilmon probes this endpoint from multiple geographic regions. If the API goes down — whether due to a process crash, a Node.js OOM, or a database failure that causes 500 errors — Vigilmon confirms via multi-region consensus and fires an alert within seconds.

Step 3: Monitor the CDN service

The CDN serves user-uploaded files, attachments, and avatar images. A CDN failure degrades the user experience significantly even when the main API is running:

Monitors → New Monitor → HTTP / HTTPS
URL: https://cdn.yourdomain.com/
Name: Spacebar CDN
Interval: 1 minute
Expected status: 200 (or 404 if your CDN returns 404 on root — adjust to match your setup)
Save

If your CDN is on a separate subdomain or port, use that URL. The key is monitoring the CDN service endpoint separately from the API so you can distinguish between "whole Spacebar is down" and "only CDN is down."

Step 4: Monitor the WebSocket gateway with a TCP probe

The Spacebar WebSocket gateway is what Discord clients connect to for real-time events. While you can't validate WebSocket handshakes with a simple HTTP probe, a TCP-level connectivity check confirms the gateway port is accepting connections:

Monitors → New Monitor → TCP Port
Host: spacebar.yourdomain.com (or your gateway IP)
Port: 3002 (default Spacebar WebSocket port, or your configured port)
Name: Spacebar WebSocket Gateway
Interval: 1 minute
Save

If you proxy the WebSocket gateway over HTTPS on port 443, monitor it as an HTTP endpoint instead:

Monitors → New Monitor → HTTP / HTTPS
URL: https://gateway.yourdomain.com/
Expected status: 426 (Upgrade Required — correct response when accessing a WebSocket endpoint without upgrading)
Name: Spacebar Gateway

A 426 response confirms the gateway is running and listening. If it returns anything other than that — or times out — the gateway is down.

Step 5: Add a database connectivity check

Database failures cause the Spacebar API to return 500 errors on most operations. The /api/ping endpoint may still return 200 even when the database is unreachable (depending on your Spacebar version). Add a deeper health check:

If your Spacebar instance exposes a /api/health endpoint or a version of ping that hits the database:

# Check if /api/health exists
curl http://your-spacebar-host:3001/api/health

If not, monitor database connectivity directly:

# Expose PostgreSQL port for TCP monitoring (if not already accessible)
# Or add a lightweight health-check endpoint to your reverse proxy config

For PostgreSQL TCP monitoring:

Monitors → New Monitor → TCP Port
Host: your database host
Port: 5432
Name: Spacebar PostgreSQL
Interval: 1 minute

When this monitor goes red while the API monitor is still green, it indicates the database is unreachable — check your database server before restarting Spacebar.

Step 6: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels → Add Channel → Email
Enter your admin or ops team email
Assign to all Spacebar monitors

Webhook alerts (Slack, Discord, PagerDuty)

Since you're running Spacebar — a Discord-compatible server — you may want to send Spacebar alerts to an admin channel on your own Spacebar instance. Or use Discord proper for ops alerts:

Alert Channels → Add Channel → Webhook

Enter your Discord/Spacebar webhook URL:

https://spacebar.yourdomain.com/api/webhooks/{webhook.id}/{webhook.token}

Assign to all Spacebar monitors

When the Spacebar API goes down, Vigilmon sends:

{
  "monitor_name": "Spacebar HTTP API",
  "status": "down",
  "url": "https://spacebar.yourdomain.com/api/ping",
  "started_at": "2024-06-01T18:00:00Z",
  "duration_seconds": 45
}

Use this to trigger automated recovery checks:

# Check Spacebar process status
systemctl status spacebar
# or for Docker:
docker ps | grep spacebar
docker logs spacebar --tail 50

# Check database connectivity
psql -h localhost -U spacebar -c "SELECT 1"

# Check disk usage (CDN storage)
df -h /var/spacebar/uploads

# Check active WebSocket connections
ss -tn | grep :3002 | wc -l

Key alert thresholds for Spacebar

| What to monitor | Alert condition | |---|---| | HTTP API /api/ping | Any non-200 response | | WebSocket gateway port | TCP connection refused or timeout | | CDN endpoint | Any non-200 response (or your expected status) | | PostgreSQL port | TCP connection refused | | CDN disk usage | >75% of available disk capacity | | WebSocket session count | Sudden drop >50% (gateway crash indicator) | | Message delivery error rate | >1% of API message requests returning errors | | Voice server process | Non-200 on voice health endpoint |

Conclusion

Spacebar gives your community or organization full control over a Discord-compatible chat infrastructure. That control comes with the responsibility of keeping it available. The HTTP API, WebSocket gateway, CDN, and database all need to be monitored separately — a failure in any one layer degrades or breaks the user experience in a distinct way.

Vigilmon gives you external uptime monitoring across all Spacebar components from multiple geographic regions, with instant alerts when any layer fails. You'll know about outages in seconds, before your users start wondering why their messages aren't sending.