How to Monitor Tinode Messaging Server with Vigilmon

Tinode is an open source, production-ready instant messaging platform written in Go. It provides everything you need to build a real-time messaging application — one-on-one messaging, group topics/channels, presence indicators, push notifications (FCM/APNS/web push), message history with full-text search, file attachments, chatbots, and multi-device sync — all on your own infrastructure.

Teams building private messaging apps, enterprise chat systems, and customer support platforms choose Tinode as a self-hosted alternative to commercial messaging APIs like Twilio, Sendbird, and Stream. Tinode exposes a WebSocket API and gRPC API for clients, and an HTTP REST API for server-side integrations. It supports multiple database backends: RethinkDB, MySQL, PostgreSQL, and MongoDB.

The tradeoff of self-hosting is full ownership of availability. When the Tinode server process crashes, all real-time messaging stops. When the database goes down, messages can't be persisted. When push notifications fail, offline users stop receiving alerts. External monitoring is the only way to catch these failures before they silently degrade your users' messaging experience.

This tutorial walks you through setting up Vigilmon monitoring for Tinode's server health, database backend, WebSocket connectivity, and push notification pipeline.

Why Tinode needs external monitoring

Tinode's Go process health doesn't tell you about database backend failures, push notification pipeline health, or WebSocket connectivity from the user perspective:

Server process crash — all WebSocket sessions terminate simultaneously; clients show "connecting…" and can't send or receive messages
Database connectivity loss — the Tinode process stays running but all message persistence fails; users see "message failed" errors with no other indication of a problem
Push notification failure — offline users stop receiving FCM/APNS push notifications; they only see messages when they manually open the app
Full-text search index failure — message search returns errors or empty results; users can't find historical messages
Disk exhaustion — file attachment uploads start failing with 500 errors while text messaging continues to work
gRPC API unavailability — server-side bots and integrations stop working while the client-facing WebSocket API remains functional

Each failure mode has a distinct symptom and a distinct recovery path. Monitoring each component separately — rather than just monitoring "is the server running" — lets you triage incidents in seconds.

What you'll need

A running Tinode server (tinode binary, Docker, or Kubernetes deployment)
Tinode's HTTP endpoint accessible (port 6060 by default)
A free Vigilmon account

Step 1: Verify the Tinode health endpoint

Tinode exposes a /.ping health probe on its HTTP port (default 6060). Verify it's responding:

curl http://your-tinode-host:6060/.ping
# tinode

A response of tinode (the literal string) confirms the server process is running and accepting HTTP connections.

If you're running Tinode behind a reverse proxy (nginx, Caddy):

curl https://tinode.yourdomain.com/.ping
# tinode

Note your endpoint URL for the next step.

Step 2: Add the Tinode server health monitor

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to https://tinode.yourdomain.com/.ping (or http://your-host:6060/.ping)
Set the check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: tinode
Name the monitor: Tinode Server Health
Save the monitor

Vigilmon probes this endpoint from multiple geographic regions simultaneously. If the Tinode process crashes, OOMs, or becomes unresponsive, Vigilmon detects via multi-region consensus and fires an alert within seconds.

Step 3: Monitor the database backend

Tinode's database backend is the most common failure point in production deployments. Add a TCP connectivity monitor for your database:

MySQL / MariaDB

Monitors → New Monitor → TCP Port
Host: your database server hostname or IP
Port: 3306
Name: Tinode MySQL
Interval: 1 minute
Save

PostgreSQL

Monitors → New Monitor → TCP Port
Host: your PostgreSQL server
Port: 5432
Name: Tinode PostgreSQL
Interval: 1 minute
Save

MongoDB

Monitors → New Monitor → TCP Port
Host: your MongoDB server
Port: 27017
Name: Tinode MongoDB
Interval: 1 minute
Save

RethinkDB

Monitors → New Monitor → TCP Port
Host: your RethinkDB server
Port: 28015
Name: Tinode RethinkDB
Interval: 1 minute
Save

When this monitor goes red while the Tinode server monitor stays green, you know immediately that the issue is database connectivity — not the Tinode process itself. This distinction cuts incident triage time significantly.

Step 4: Monitor the WebSocket API with a TCP probe

Tinode's WebSocket endpoint is what mobile and web clients connect to for real-time messaging. Add a TCP connectivity check to confirm the WebSocket port is accepting connections:

Monitors → New Monitor → TCP Port
Host: tinode.yourdomain.com
Port: 6060 (or your WebSocket port if different from the HTTP port)
Name: Tinode WebSocket Port
Interval: 1 minute
Save

If you use a reverse proxy that terminates TLS and forwards WebSocket on port 443, monitor the HTTP endpoint instead. The Tinode /.ping endpoint responds over the same connection so Step 2 already covers this if you're on the same port.

For deployments where WebSocket is on a separate port, add the dedicated TCP monitor to distinguish between "HTTP API is up" and "WebSocket port is accepting connections."

Step 5: Monitor push notification pipeline health

Tinode's push notification pipeline (FCM for Android, APNS for iOS) is critical for offline users. Build a lightweight push health probe that verifies FCM connectivity:

# Quick FCM connectivity test using Tinode's REST API
# Submit a test push and check the response
curl -s -X POST https://tinode.yourdomain.com/v0/push \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'admin:your-admin-password' | base64)" \
  -d '{"test": true}' | grep -q '"code":200'

Alternatively, monitor Tinode's metrics endpoint if you have Prometheus metrics enabled:

# Enable metrics in tinode.conf:
# "expvar": true

curl http://your-tinode-host:6060/debug/vars

Add an HTTP monitor for the metrics endpoint:

Monitors → New Monitor → HTTP / HTTPS
URL: http://your-tinode-host:6060/debug/vars
Name: Tinode Metrics Endpoint
Expected status: 200
Interval: 2 minutes

A non-200 response here indicates the Tinode debug subsystem is unhealthy — a leading indicator of process instability.

Step 6: Monitor disk usage for file attachments

File attachment uploads accumulate on disk over time. As disk usage grows toward 100%, new uploads start failing with 500 errors. Add a disk usage monitoring script that exposes a health endpoint:

# disk-health.sh — run as a cron job every 5 minutes
#!/bin/bash
THRESHOLD=80
UPLOAD_DIR=/path/to/tinode/uploads

USAGE=$(df "$UPLOAD_DIR" | tail -1 | awk '{print $5}' | tr -d '%')

if [ "$USAGE" -lt "$THRESHOLD" ]; then
  echo "{\"disk_usage_pct\":$USAGE,\"status\":\"ok\"}" > /var/www/health/disk.json
else
  echo "{\"disk_usage_pct\":$USAGE,\"status\":\"warning\"}" > /var/www/health/disk.json
fi

Serve this file via nginx and monitor it:

Monitors → New Monitor → HTTP / HTTPS
URL: https://tinode.yourdomain.com/health/disk.json
Name: Tinode Disk Usage
Response body contains: "status":"ok"
Interval: 5 minutes

When disk usage exceeds 80%, Vigilmon alerts you so you can provision additional storage or clean up old attachments before uploads start failing.

Step 7: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels → Add Channel → Email
Enter your on-call or backend team email
Assign to all Tinode monitors

Webhook alerts (Slack, PagerDuty, Opsgenie)

Alert Channels → Add Channel → Webhook
Enter your Slack webhook URL or PagerDuty Events API endpoint
Assign to all Tinode monitors

When Tinode goes down, Vigilmon sends:

{
  "monitor_name": "Tinode Server Health",
  "status": "down",
  "url": "https://tinode.yourdomain.com/.ping",
  "started_at": "2024-06-01T20:00:00Z",
  "duration_seconds": 30
}

Use this to trigger automated investigation:

# Check Tinode process status
systemctl status tinode
# or for Docker:
docker ps | grep tinode
docker logs tinode --tail 100

# Check database connectivity from the Tinode server
# For MySQL:
mysql -h localhost -u tinode -p -e "SELECT 1"

# Check active WebSocket sessions
ss -tn | grep :6060 | wc -l

# Check disk usage for attachments
df -h /path/to/tinode/uploads

# Check if gRPC API is responsive
grpc_health_probe -addr=localhost:16060

Key alert thresholds for Tinode

| What to monitor | Alert condition | |---|---| | Server /.ping | Any non-200 response or body not tinode | | Database TCP port | Connection refused or timeout | | WebSocket TCP port | Connection refused or timeout | | Push notification API | FCM/APNS error rate >5% | | File upload success rate | >1% upload errors | | Disk usage (uploads) | >80% of disk capacity | | Message delivery P95 latency | >500ms (database or Tinode under pressure) | | gRPC API health | Any non-SERVING status | | Active WebSocket sessions | Sudden drop >50% (server-side WebSocket failure) | | Cluster node connectivity | Any node partition event (if multi-node) |

Conclusion

Tinode gives you a production-grade, self-hosted messaging backend with the features of commercial APIs at zero licensing cost. The tradeoff is full operational ownership — and the operational surface covers the Go server process, database backend, push notification pipeline, file storage, and gRPC API independently.

Vigilmon gives you external monitoring across all these layers with multi-region consensus-based alerting and zero infrastructure overhead. No Prometheus. No Grafana. No alert manager YAML. Add your Tinode health endpoints, configure an email or webhook channel, and you'll catch outages in seconds before users notice their messages aren't delivering.