Monitoring OpenSign with Vigilmon

OpenSign gives you legally-binding electronic signatures without sending sensitive legal documents to Docusign or PandaDoc. The Node.js backend, MongoDB document store, and email notification queue are all yours — which means when MongoDB goes down, signature requests fail silently. When the email queue breaks, signatories never receive their signing links and legal deadlines get missed. Vigilmon monitors the full OpenSign stack: web application availability, API health, database connectivity, and workflow health through heartbeat monitoring.

What You'll Set Up

• HTTP uptime monitor for the OpenSign web application
• API health endpoint monitor with keyword verification
• TCP probe to MongoDB for independent database health monitoring
• SSL certificate expiry alerts for HTTPS OpenSign deployments
• Heartbeat monitoring for the OpenSign email notification workflow

Prerequisites

• OpenSign deployed via Docker Compose or manual Node.js installation
• OpenSign web UI accessible on port 3000 (or behind a reverse proxy)
• MongoDB running and accessible on port 27017
• A free Vigilmon account

Step 1: Monitor OpenSign Web Application Availability

OpenSign serves a React SPA from a Node.js server on port 3000. A 200 response confirms the server process is running:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your OpenSign URL: http://opensign.yourdomain.com (or https:// if behind a TLS-terminating reverse proxy).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

If OpenSign is running behind nginx or Caddy, monitor the public-facing URL — this also validates that the reverse proxy is routing correctly to the Node.js process.

Step 2: Monitor the OpenSign API Health Endpoint

The Node.js API can be running while the application is degraded (MongoDB connection lost, configuration error). Monitor the health endpoint directly to get a richer signal:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://opensign.yourdomain.com/api/health (try /api/app/health if the first returns 404 — the exact path depends on your OpenSign version).
3. Set Check interval to 2 minutes.
4. Enable Keyword check and enter ok or status as the expected keyword.
5. Set Expected HTTP status to 200.
6. Click Save.

The health endpoint returns a JSON response like {"status":"ok"} when the API and its dependencies are healthy. Keyword monitoring for ok confirms the application is reporting healthy, not just that the HTTP server is listening.

Step 3: TCP Probe MongoDB Connectivity

OpenSign stores all documents, users, templates, and signature records in MongoDB. If MongoDB becomes unavailable, OpenSign cannot load documents, process signature requests, or retrieve audit trails — but the Node.js process itself may continue running and returning partial responses. Monitor MongoDB independently:

1. Click Add Monitor → TCP Port.
2. Enter your MongoDB server hostname or IP address.
3. Set Port to 27017.
4. Set Check interval to 1 minute.
5. Click Save.

A TCP connection to port 27017 confirms MongoDB is accepting connections. This is faster and more direct than waiting for the OpenSign API health check to reflect a database failure — MongoDB connection timeouts can take 30+ seconds to propagate to the application layer.

If MongoDB is running on the same host as OpenSign and not exposed externally, point the Vigilmon probe at the host's IP address and ensure port 27017 is accessible from Vigilmon's probe network (or use a Vigilmon agent installed on the same network).

Step 4: SSL Certificate Alerts for HTTPS OpenSign

E-signing platforms must use HTTPS — signatories receive email links to signing pages, and an expired TLS certificate breaks those links in browsers. A signatory clicking a signing link and seeing a certificate error will not complete the signature, and the document originator has no visibility into why. Add SSL monitoring:

1. Open the HTTPS monitor created in Step 1.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

Legal and compliance teams using OpenSign often have hard deadlines for document signing (contract execution dates, regulatory submissions). A certificate failure that blocks the signing workflow 10 days before a deadline is a business-critical event — the 21-day alert window gives you time to renew before any deadline conflicts arise.

Step 5: Heartbeat Monitoring for OpenSign Email Notifications

OpenSign sends email notifications to signatories when documents are ready to sign, and to document creators when signatures are completed. A broken email queue (SMTP misconfiguration, sending limit exceeded, environment variable change) silently prevents signature requests from reaching recipients — no alert, no bounce, just missed signatures.

Configure a heartbeat that validates the full signature request workflow:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Name it OpenSign Email Workflow Heartbeat.
3. Set the expected ping interval to 60 minutes (for an hourly workflow test).
4. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).

Create a scheduled test script that exercises the OpenSign API and pings Vigilmon on success:

#!/bin/bash
# OpenSign workflow health check — run via cron every hour
# Requires: OPENSIGN_API_URL, OPENSIGN_API_KEY environment variables

OPENSIGN_URL="${OPENSIGN_API_URL:-http://localhost:3000}"
API_KEY="${OPENSIGN_API_KEY}"
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/abc123"

# Test API connectivity
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -H "X-Parse-Application-Id: ${API_KEY}" \
  "${OPENSIGN_URL}/api/health")

if [ "$HTTP_STATUS" = "200" ]; then
  # API is healthy — ping Vigilmon heartbeat
  curl -s --max-time 10 "${VIGILMON_HEARTBEAT}"
  echo "$(date): OpenSign health check passed"
else
  echo "$(date): OpenSign health check failed — HTTP ${HTTP_STATUS}" >&2
fi

Add to cron:

# /etc/cron.d/opensign-health
0 * * * * root /usr/local/bin/opensign-healthcheck.sh >> /var/log/opensign-health.log 2>&1

If the API becomes unreachable or returns a non-200 status, the curl ping is skipped and Vigilmon alerts after the expected interval passes. This provides visibility into the Node.js + email stack health without requiring a test document to be sent to a real signatory.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add email, Slack, or a webhook.
2. For the MongoDB TCP probe, set Consecutive failures before alert to 1 — database unavailability is an immediate outage for all OpenSign operations.
3. For the web application monitor, set Consecutive failures before alert to 2 to absorb brief Node.js restarts during deployments.
4. Tag monitors with opensign to group them in the Vigilmon dashboard.
5. Use a Maintenance window in Vigilmon when upgrading OpenSign (a Docker Compose docker compose pull && docker compose up -d causes a brief downtime):

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 5}'

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP availability | http(s)://opensign.domain.com | Node.js server crash, proxy failure | | API health | /api/health — keyword "ok" | Application error, dependency failure | | TCP port 27017 | MongoDB host | Database unavailability | | SSL certificate | HTTPS OpenSign URL | Certificate expiry, signing link breakage | | Cron heartbeat | Workflow heartbeat URL | Email queue failure, API degradation |

OpenSign eliminates $25–65/user/month Docusign costs and keeps your legal documents on your own infrastructure — but that ownership means email deliverability, database availability, and TLS health are your responsibility. With Vigilmon monitoring all five signal layers, you get advance warning before a certificate expiry blocks a contract signing or a MongoDB crash halts your document workflow.