Monitoring Apostrophe CMS with Vigilmon: Express.js Web App, REST API Health, MongoDB TCP Probe & Media Storage Heartbeat

Apostrophe CMS powers content-heavy websites for agencies, non-profits, and organizations that need in-context editing with a JavaScript-native stack. The platform depends on three layers: the Express.js web server, the MongoDB database for all content, and either local filesystem or S3 storage for uploaded media. Any one of these failing silently can result in a website that appears to load but returns empty pages, broken images, or stale content — and since Apostrophe doesn't have a built-in health dashboard visible to external visitors, editors and site owners may not notice for hours. Vigilmon gives you external monitoring over every critical Apostrophe layer: the web application, the REST API, MongoDB connectivity, SSL certificate expiry, and the content and media storage read paths.

What You'll Build

• An HTTP monitor on the Apostrophe web application (port 3000) for Express.js availability
• An HTTP monitor on the Apostrophe REST API login route to confirm the API router and auth module are loaded
• A TCP monitor on MongoDB port 27017 for early database failure detection
• An SSL certificate monitor for HTTPS-proxied Apostrophe deployments
• A heartbeat monitor to confirm content read path health and media storage availability

Prerequisites

• Apostrophe CMS running on your server (default Express.js port 3000)
• MongoDB running on the same or a separate server (default port 27017)
• A domain or IP accessible from the internet
• A free account at vigilmon.online

Step 1: Check the Apostrophe Web Application

Apostrophe serves the public-facing website and the admin interface on the same Express.js port (default 3000). A GET request to the root URL confirms the server is running and MongoDB is accessible — Apostrophe fails to start or serve pages when it cannot connect to MongoDB on startup:

curl -I http://apostrophe.yourdomain.com:3000/
# HTTP/1.1 200 OK

A 200 response confirms the Express.js server has initialized, the MongoDB connection is active, and Apostrophe's page rendering pipeline is functional.

Step 2: Create the Web Application Monitor in Vigilmon

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://apostrophe.yourdomain.com/
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds (Apostrophe cold starts with MongoDB queries can be slow).
5. Expected status: 200.
6. Keyword: your site's name or a unique string from the public homepage (e.g., your organization name in the page title).
7. Label: Apostrophe Web App
8. Click Save.

This monitor catches:

• Node.js process crashes or PM2 restarts that fail to recover
• MongoDB connection failures that cause Apostrophe to return 500 errors
• Express.js middleware errors that break all route handling
• Port conflicts or process limits that prevent the server from binding to port 3000

Step 3: Monitor the Apostrophe REST API

Apostrophe exposes a REST API via the @apostrophecms/rest-api module and has a built-in login route at /@apostrophecms/login (the admin login page). A GET request to this route confirms the Express.js router is fully initialized and the auth module is loaded:

curl -I http://apostrophe.yourdomain.com:3000/@apostrophecms/login
# HTTP/1.1 200 OK

For Apostrophe installations with the REST API module, you can also check the API endpoint:

curl -I http://apostrophe.yourdomain.com:3000/api/v1/@apostrophecms/login
# HTTP/1.1 200 OK  (or 405 Method Not Allowed — both confirm the route is registered)

1. Add Monitor → HTTP.
2. URL: https://apostrophe.yourdomain.com/@apostrophecms/login
3. Expected status: 200.
4. Keyword: apostrophe or login (present in the admin login page HTML).
5. Check interval: 120 seconds.
6. Label: Apostrophe Admin API
7. Click Save.

If the homepage returns 200 but the admin login route fails, the problem is in Apostrophe's module initialization rather than the core Express.js server — this can happen when a custom module throws an error during startup that doesn't crash the process but leaves routes unregistered.

Step 4: TCP Probe on MongoDB Port 27017

Apostrophe requires MongoDB for all content operations — page rendering, media queries, widget data, and API responses all depend on MongoDB. A MongoDB crash or connection refusal causes Apostrophe to return 500 errors or empty pages. Monitoring MongoDB directly on TCP port 27017 gives you early warning before failures cascade to the web application:

# Test MongoDB TCP connectivity
nc -zv mongodb.yourdomain.com 27017
# Connection to mongodb.yourdomain.com 27017 port [tcp] succeeded!

1. Add Monitor → TCP.
2. Host: mongodb.yourdomain.com (or localhost / internal IP if MongoDB is on the same host).
3. Port: 27017
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Apostrophe MongoDB
7. Click Save.

The TCP monitor fires an alert the moment MongoDB stops accepting connections — before Apostrophe's own connection pool exhausts and begins returning errors. This gives you a head start on database investigation before editors notice the CMS is broken.

If MongoDB is not directly accessible from the internet (recommended), run Vigilmon's internal agent on the same network, or configure the heartbeat in Step 6 to include a MongoDB-level connectivity check from the server itself.

Step 5: Monitor Your SSL Certificate

Apostrophe CMS production sites are typically reverse-proxied behind nginx or Caddy for HTTPS. A certificate expiry on your production domain makes the entire website — both the public site and the admin interface — inaccessible via HTTPS, locking editors out of the CMS:

1. Add Monitor → SSL Certificate.
2. Domain: apostrophe.yourdomain.com
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days.
5. Label: Apostrophe SSL Certificate

For multi-site Apostrophe deployments, add an SSL monitor for each domain served by the installation. A certificate expiry on a subdomain that's served by the same Apostrophe instance will only affect that domain — per-domain SSL monitoring catches this.

Step 6: Content and Media Storage Heartbeat

Apostrophe's content read path and media storage have two independent failure modes that both produce 200 HTTP responses while silently breaking the site:

1. MongoDB read path failure: The web app returns 200 but renders empty pages because MongoDB queries are failing or timing out. This can happen when MongoDB is running but under severe I/O pressure, replica set elections are in progress, or the Apostrophe database collections have become corrupted.

2. Media storage unavailability: Apostrophe stores uploaded images and files either on the local filesystem or in an S3 bucket. If the uploads directory gets unmounted or S3 credentials expire, the web app continues serving pages but all images return 404 errors.

Set up a server-side heartbeat that checks both:

#!/bin/bash
# /etc/cron.d/apostrophe-content-heartbeat — runs every 5 minutes

APOSTROPHE_HOST="http://localhost:3000"
# Adjust to your Apostrophe uploads directory (local storage)
UPLOADS_DIR="/path/to/apostrophe/public/uploads"

# Check 1: Can we reach the Apostrophe homepage and get content?
HTTP_STATUS=$(curl -fsS -o /dev/null -w "%{http_code}" \
  "$APOSTROPHE_HOST/" 2>/dev/null)

# Check 2: Is the uploads directory mounted and writable?
UPLOADS_OK=false
if [ -d "$UPLOADS_DIR" ] && [ -r "$UPLOADS_DIR" ]; then
  UPLOADS_OK=true
fi

if [ "$HTTP_STATUS" = "200" ] && [ "$UPLOADS_OK" = "true" ]; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

For S3-backed Apostrophe deployments, replace the uploads directory check with an S3 bucket head request:

# S3 storage availability check (requires aws-cli configured)
S3_OK=$(aws s3 ls "s3://your-apostrophe-bucket/" --max-items 1 2>/dev/null && echo "ok" || echo "fail")

if [ "$HTTP_STATUS" = "200" ] && [ "$S3_OK" = "ok" ]; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

In Vigilmon:

1. Add Monitor → Heartbeat.
2. Expected interval: 5 minutes.
3. Grace period: 15 minutes.
4. Label: Apostrophe Content & Media

When either the content read path or the media storage becomes unavailable, the heartbeat stops and Vigilmon alerts you — before editors notice broken images or empty page content.

Common Apostrophe CMS Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Node.js process crash or PM2 failure | Web app monitor detects connection refused; alert fires within 60 s | | MongoDB connection failure on startup | Web app returns 500; TCP probe on 27017 fires simultaneously | | MongoDB crash while app is running | TCP probe detects connection refused; web app 500s follow within seconds | | Module initialization error (route not registered) | Web app returns 200; admin login route returns 404 or 500 | | Local uploads directory unmounted | Web app returns 200; content/media heartbeat stops | | S3 credentials expired (media storage) | Web app serves broken image tags; media heartbeat stops | | nginx/Caddy reverse proxy misconfiguration | All external monitors fail; Node.js may still be running on port 3000 | | SSL certificate expires on production domain | SSL monitor alerts at 30 days; editors locked out of admin | | MongoDB replica set election in progress | TCP probe stays green; content heartbeat stops during election window | | Apostrophe cache warming failure (cold start slow) | Response timeout on web app monitor fires on first check post-restart |

Apostrophe CMS is a capable JavaScript-native CMS, but self-hosted deployments sit at the intersection of three independent systems — Node.js, MongoDB, and object storage — each with its own failure modes. Vigilmon monitoring covers all three layers plus SSL and the content read path, giving you external visibility into every failure mode before editors or site visitors discover a broken CMS.

Start monitoring Apostrophe CMS in under 5 minutes — register free at vigilmon.online.