Cusdis Monitoring with Vigilmon: Health API, Database & Email Delivery Uptime

A reader left a thoughtful comment on your blog three days ago. You never saw it. Cusdis had been running — technically — but the PostgreSQL connection had dropped after a routine server reboot and the /api/health endpoint was returning 503s. New comments were being lost silently, and the email notifications that should have alerted you had stopped firing.

Cusdis is a self-hosted, open-source lightweight comment system designed as a privacy-friendly Disqus alternative. It is built with Next.js, stores comments in PostgreSQL, and sends email notifications when new comments arrive. It runs on port 3000 by default and is typically proxied behind Nginx or Caddy. Vigilmon monitors Cusdis externally — checking the web server, the API health endpoint, and confirming that email notification delivery is working — so silent failures never stay silent.

This tutorial sets up complete monitoring for a self-hosted Cusdis instance.

What You'll Build

• A Vigilmon HTTP monitor on the Cusdis web interface
• A monitor on the /api/health endpoint for database connectivity
• A heartbeat monitor to confirm email notification delivery
• SSL certificate alerts for proxied deployments

Prerequisites

• A running Cusdis instance (default port 3000, or proxied via Nginx/Caddy)
• A free account at vigilmon.online

Step 1: Monitor the Cusdis Web Interface

Cusdis serves its admin dashboard at the root path. When the Next.js server is running and PostgreSQL is accessible, a GET to the root returns a 200 with the login page or dashboard HTML.

Test the endpoint:

curl -I http://your-server:3000/

Expected:

HTTP/1.1 200 OK
content-type: text/html; charset=utf-8

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to https://comments.yourdomain.com/ (or http://your-server:3000/ if not proxied).
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Save.

This baseline check catches server process crashes, reverse proxy failures, and host-level outages.

Step 2: Monitor the /api/health Endpoint

Cusdis exposes a dedicated health check endpoint at /api/health. This endpoint verifies that the application can connect to PostgreSQL and returns a JSON status object.

Test it:

curl https://comments.yourdomain.com/api/health

Expected response:

{"status": "ok"}

If PostgreSQL is unreachable, the connection pool is exhausted, or the database schema is out of date after a failed migration, this endpoint returns a non-200 status or a JSON error body.

Set up the health endpoint monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://comments.yourdomain.com/api/health.
3. Set Expected status code to 200.
4. Under Advanced → Keyword check, configure:
   • Keyword present: "ok"
   • Keyword absent: "error"
5. Save.

This monitor is more sensitive than the root URL check — it specifically validates database connectivity, not just web server availability.

Step 3: Heartbeat Monitor for Email Notification Delivery

Cusdis sends email notifications when new comments are approved (depending on your moderation settings). Email delivery failures are invisible from the outside: the web interface works, the database stores comments, but owners never find out about new activity.

Email delivery depends on your configured SMTP provider (Sendgrid, Mailgun, self-hosted SMTP, etc.). A Vigilmon heartbeat confirms that the email pathway is alive by having a cron job on the Cusdis host verify SMTP connectivity and send a ping.

# crontab -e
*/15 * * * * curl -fsS "smtp://your-smtp-host:587" --mail-from "health@yourdomain.com" --mail-rcpt "health@yourdomain.com" --upload-file /dev/null > /dev/null 2>&1 && curl -fsS https://vigilmon.online/api/heartbeat/<your-heartbeat-id> > /dev/null 2>&1

Or if your SMTP check is complex, use a simpler process-alive approach:

*/5 * * * * systemctl is-active --quiet cusdis && curl -fsS https://vigilmon.online/api/heartbeat/<your-heartbeat-id> > /dev/null 2>&1

Set up the heartbeat in Vigilmon:

1. Click New Monitor → Heartbeat.
2. Set Expected interval to 15 minutes (or 5 minutes for the simpler version).
3. Set Grace period to 20 minutes.
4. Copy the ping URL and add it to your cron job.
5. Save.

Step 4: Database Connectivity (PostgreSQL)

Cusdis requires PostgreSQL. The /api/health endpoint in Step 2 already validates the database connection on every request. For an additional database-layer heartbeat that fires only when PostgreSQL is responding:

# crontab -e
*/5 * * * * pg_isready -h localhost -U cusdis -d cusdis && curl -fsS https://vigilmon.online/api/heartbeat/<your-db-heartbeat-id> > /dev/null 2>&1

Create a separate Heartbeat monitor in Vigilmon with a 5-minute interval for this check. If PostgreSQL becomes unavailable between cron ticks, the /api/health monitor will catch it first — this heartbeat provides belt-and-suspenders coverage at the database layer specifically.

Step 5: SSL Certificate Alerts

Cusdis is typically embedded in websites via a JavaScript widget. If your SSL certificate expires, the widget fails to load on all the sites using it — not just the Cusdis admin panel. Comment boxes simply disappear from your visitors' view.

1. Open the HTTP monitor from Step 1.
2. Go to Advanced → SSL certificate monitoring.
3. Enable Alert when certificate expires within and set it to 30 days.
4. Save.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon:

• Email — immediate alerts to the site owner
• Webhook — post to Slack or trigger a notification pipeline

A Cusdis health alert looks like:

🔴 DOWN: comments.yourdomain.com/api/health
Expected keyword '"ok"' not found — status 503
Region: US-East
Triggered: 2026-01-15 04:22 UTC

Recovery:

✅ RECOVERED: comments.yourdomain.com/api/health
Downtime: 18 minutes

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | Cusdis Next.js process crash | Web UI HTTP monitor detects non-200 | | PostgreSQL unreachable | /api/health monitor returns 503 or error keyword | | PostgreSQL connection pool exhausted | /api/health monitor detects degraded response | | Email/SMTP failure (lost notifications) | Heartbeat ping stops arriving | | Reverse proxy (Nginx/Caddy) down | Web UI monitor detects 502 or connection refused | | SSL certificate expired (widget breaks) | Certificate expiry alert fires 30 days before | | Database migration failure | /api/health returns error state | | Server host offline | All monitors and heartbeat fire simultaneously |

Cusdis earns its reputation for simplicity and privacy — but simple doesn't mean failure-free. A broken database connection or a stalled SMTP configuration can silently cut you off from your readers' feedback. Vigilmon monitors every layer so you never miss a comment because of infrastructure you forgot to watch.

Start monitoring your Cusdis instance today — register free at vigilmon.online.