tutorial

Monitoring Ferdium Server with Vigilmon: Service Availability, /healthz Endpoint, SQLite Connectivity & SSL Certificates

How to monitor a self-hosted Ferdium server with Vigilmon — service availability at port 3333, /healthz health endpoint, database connectivity, SSL certificates, and heartbeat monitoring.

Ferdium is a self-hosted messaging aggregator that lets teams sync their messaging workspaces — Slack, WhatsApp, Gmail, and dozens of others — across devices through a central server. When the Ferdium server goes down, workspace configurations stop syncing, users lose their service layouts on new devices, and the central server-side session store becomes inaccessible. Vigilmon gives you external visibility into your Ferdium server so you catch failures before users notice: service availability, the /healthz endpoint, database connectivity, SSL certificate expiry, and a heartbeat to confirm the sync service keeps running.

What You'll Build

  • A monitor on Ferdium server availability at its default port
  • A check on the /healthz health endpoint
  • Indirect database connectivity verification
  • SSL certificate monitoring if you proxy Ferdium over HTTPS
  • A heartbeat to confirm the sync service stays running

Prerequisites

  • A running Ferdium server instance (default port 3333)
  • A free account at vigilmon.online

Step 1: Verify Ferdium Server Is Running

Ferdium server (based on Franz server) runs on port 3333 by default. Confirm it is accessible:

curl -I http://your-ferdium-server:3333/
# Or if proxied:
curl -I https://ferdium.example.com/

A running Ferdium server returns a 200 OK response. The root path serves a simple status page or API response — the server is built on AdonisJS and responds quickly.

Step 2: Create a Vigilmon Monitor for Service Availability

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: http://your-ferdium-server:3333/ (or your proxied HTTPS URL).
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Click Save.

This monitor catches Node.js process crashes, OOM kills, and network-level outages. When the Ferdium server is down, clients cannot sync their workspace configurations or authenticate.

Step 3: Monitor the /healthz Endpoint

Ferdium server exposes a /healthz endpoint that confirms the application is alive and its dependencies (database, storage) are reachable:

curl https://ferdium.example.com/healthz

A healthy Ferdium server returns a 200 OK with a simple status response indicating the service is up. This endpoint is lighter than the root path and is specifically designed for health checking:

  1. Add Monitor → HTTP.
  2. URL: https://ferdium.example.com/healthz.
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Label: Ferdium /healthz.
  6. Click Save.

The /healthz endpoint is the primary indicator that the Ferdium application layer is fully operational — not just that the HTTP server is accepting connections. Use this as your main alert trigger.

Step 4: Verify Database (SQLite) Connectivity

Ferdium server uses SQLite for storing user accounts, workspace configurations, and sync data. SQLite failures are typically caused by disk full conditions, file permission errors, or corrupted database files.

You can detect database failures externally by checking the user authentication endpoint:

curl -X POST https://ferdium.example.com/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"invalid@test.com","password":"invalid"}'

A database-connected Ferdium server returns 401 Unauthorized (correct credentials rejected) — which proves the auth stack and database are functioning. If the database is inaccessible, you'll get a 500 Internal Server Error instead.

Add this monitor:

  1. Add Monitor → HTTP (POST).
  2. URL: https://ferdium.example.com/v1/auth/login.
  3. Method: POST.
  4. Headers: Content-Type: application/json.
  5. Body: {"email":"monitor-check@invalid.local","password":"invalid"}.
  6. Expected status: 401 (unauthenticated request confirms the DB-backed auth layer is alive).
  7. Label: Ferdium auth API (DB connectivity).
  8. Click Save.

A 401 response is the correct health signal here. If Ferdium returns 500, the database layer has failed.

Step 5: Monitor SSL Certificates

If you run Ferdium server behind a reverse proxy (nginx, Caddy, Traefik), the SSL certificate on that proxy is what Ferdium clients trust for sync connections. An expired certificate breaks sync for all clients immediately:

  1. Add Monitor → SSL Certificate.
  2. Domain: ferdium.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Ferdium clients that connect over HTTPS will immediately fail with certificate errors when the certificate expires — users will be unable to sync or authenticate until the certificate is renewed.

Step 6: Set Up a Vigilmon Heartbeat for Sync Service Health

A Vigilmon heartbeat confirms that the Ferdium sync service is actively processing and not silently stalled. Set up a cron-based heartbeat on your server:

# Add to crontab — confirms /healthz responds every 5 minutes
*/5 * * * * curl -sf https://ferdium.example.com/healthz && curl -s "https://your-heartbeat-url.vigilmon.online/ping"

In Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Expected interval: 5 minutes.
  3. Grace period: 2 minutes.
  4. Label: Ferdium sync service.
  5. Copy the heartbeat ping URL and add it to your cron script.

If the Ferdium server stops responding to /healthz — due to a crash, resource exhaustion, or disk issues — the heartbeat stops sending pings and Vigilmon alerts after the grace period.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Service availability | Non-200 response | Check pm2 status ferdium-server or docker ps; inspect logs | | /healthz | Non-200 response | Ferdium not fully healthy; check disk space and SQLite file | | Auth API (DB connectivity) | Non-401 response | SQLite likely inaccessible; check file permissions and disk | | SSL certificate | < 30 days to expiry | Renew certificate; check ACME on reverse proxy | | Heartbeat | Missing ping | Full-stack issue; check cron job and server health |

Alert after: 2 consecutive failures for general availability; 1 failure for the /healthz endpoint — a /healthz failure is a definitive signal of server distress.

Common Ferdium Server Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Node.js process crash | Service availability monitor fires within 60 s | | SQLite disk-full or corruption | Auth API returns 500; /healthz may also fail | | Disk full (SQLite write failure) | /healthz monitor fires; check df -h on the server | | SSL certificate expired | SSL monitor alerts at 30-day threshold | | OOM kill on constrained server | Service availability fires; check container/VM memory limits | | Reverse proxy misconfiguration | All monitors fire; web server check confirms proxy is the issue | | Node.js crash loop on startup | /healthz never becomes healthy; availability monitor fires |

A self-hosted Ferdium server is often a low-visibility service — it runs quietly in the background and its failures only surface when a user tries to set up Ferdium on a new device. Vigilmon gives you continuous external monitoring of the service availability, health endpoint, database layer, and SSL certificates so you can fix problems before users even notice their workspaces aren't syncing.

Start monitoring Ferdium server in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles