How to Monitor Your Self-Hosted Chatwoot Instance with Vigilmon

Chatwoot turns your support operation from a pile of email threads into a structured, multi-agent inbox. When you self-host it, you inherit full control — and full responsibility for keeping it running. A downed Chatwoot instance doesn't just frustrate your support team; it means customer messages go unacknowledged and conversations drop entirely.

This guide sets up four monitoring layers with Vigilmon: the authentication API, web UI, ActionCable WebSocket port, and SSL certificate.

What can go wrong with a self-hosted Chatwoot

Chatwoot's stack includes a Rails API, a Sidekiq background worker, ActionCable for real-time updates, and typically a PostgreSQL database and Redis. Each is a potential failure point:

• Rails API down — agents can't log in, incoming conversations don't appear, API integrations stop delivering messages
• Sidekiq workers stopped — email notifications stop sending, webhook deliveries queue up and are never processed
• ActionCable WebSocket fails — agents stay logged in but the inbox stops updating in real time; they don't see new messages without a page refresh
• SSL certificate expires — the entire site becomes inaccessible from browsers; your customers' chat widgets may also break

Step 1: Monitor the authentication API

The /auth/sign_in endpoint is an ideal health signal — it's on the critical path for every agent session, and it exercises the Rails app, database connectivity, and the authentication layer at once.

In Vigilmon:

1. Click New Monitor → HTTP
2. URL: https://chatwoot.yourdomain.com/auth/sign_in
3. Expected status: 200 (the page renders) or 405 (POST-only — an HTTP GET returns method not allowed, which still means the app is up)
4. Check interval: 5 minutes
5. Save

If the Rails process crashes or the database goes down, this endpoint stops responding. You'll get an alert within minutes.

Tip: If you want to test actual authentication, use an HTTP monitor with a POST body. But for uptime purposes, a GET returning a 4xx on the login page is enough to confirm the app is alive.

Step 2: Monitor the web UI availability

Add a second monitor for the root URL to catch failures where the API is responding but the frontend assets aren't being served:

1. Click New Monitor → HTTP
2. URL: https://chatwoot.yourdomain.com
3. Expected status: 200
4. Check interval: 5 minutes
5. Save

| Monitor | URL | What it catches | |---|---|---| | Auth API | /auth/sign_in | Rails crash, DB failure | | Web UI | / | Asset serving failure, nginx misconfiguration |

Step 3: Monitor the ActionCable WebSocket TCP port

Chatwoot's real-time inbox updates rely on ActionCable, Rails' WebSocket implementation. When ActionCable goes down, agents don't see new conversations in real time — a subtle but deeply painful failure mode that's invisible to HTTP monitors.

ActionCable runs on the same port as the Rails app (typically 443 behind a reverse proxy), but WebSocket upgrades require specific nginx or Caddy configuration. After any reverse proxy config change, WebSocket upgrades can silently break while HTTP requests continue to succeed.

In Vigilmon:

1. Click New Monitor → TCP Port
2. Host: chatwoot.yourdomain.com
3. Port: 443
4. Check interval: 5 minutes
5. Save

If you run ActionCable on a separate port (less common, but possible in some Docker Compose setups), monitor that port instead.

Step 4: Monitor SSL certificate expiry

Chatwoot is almost always served over HTTPS — your customers' chat widgets and agent browsers will hard-block an expired certificate.

In Vigilmon:

1. Click New Monitor → SSL Certificate
2. Domain: chatwoot.yourdomain.com
3. Alert threshold: 14 days before expiry
4. Save

Fourteen days of warning gives you time to investigate a broken certbot renew systemd timer or a DNS validation failure before it becomes a customer-facing incident.

Step 5: Set up Slack or email alerts

In Vigilmon, go to Notifications → New Channel and connect Slack, Discord, or email. Assign the channel to all four monitors.

Alert example when Chatwoot goes down:

🔴 DOWN: chatwoot.yourdomain.com/auth/sign_in
Status: 502 Bad Gateway
Regions: US-East, EU-West
Started: 3 minutes ago

Recovery notification:

✅ RECOVERED: chatwoot.yourdomain.com/auth/sign_in
Total downtime: 11 minutes

With all four monitors sending to the same channel, you get one place to see the full health picture instead of discovering issues from an angry support agent.

Step 6: Add a public status page

Create a Vigilmon status page to communicate with your support team during incidents:

1. Go to Status Pages → New Status Page
2. Add all four monitors
3. Publish the URL and pin it in your #support-ops or internal tools channel

During an incident, team members can check the status page themselves instead of pinging you for updates.

What you're monitoring

| Monitor | Type | Catches | |---|---|---| | Auth API /auth/sign_in | HTTP | Rails crash, database failure | | Web UI | HTTP | Asset serving, nginx failure | | ActionCable WebSocket | TCP Port | Real-time update failures | | SSL Certificate | SSL | Cert expiry before outage |

With these in place, Chatwoot downtime is a five-minute alert — not a support manager asking why the inbox has been empty for an hour.

Get started free at vigilmon.online — your first monitor is running in under a minute.