Monitoring DocuSeal with Vigilmon: Root Path Check, API Alive Endpoint, SSL Alerts & Uptime Monitoring

DocuSeal is a self-hosted, open-source alternative to DocuSign — giving you full control over your document signing workflows without sending contracts to third-party cloud providers. As a document signing platform, DocuSeal occupies a uniquely sensitive position: when it goes down, contracts can't be signed, employment agreements stall, vendor agreements are delayed, and legally time-sensitive documents go unsigned. Unlike most SaaS tools where downtime is an inconvenience, DocuSeal outages can have direct legal and financial consequences. Vigilmon watches DocuSeal's availability so you're alerted before a signing ceremony fails or a time-sensitive deadline is missed.

What You'll Build

• An HTTP monitor for DocuSeal's root path (200 response = app is running)
• An HTTP monitor for the API endpoint (401 = alive, database is responding)
• An SSL certificate monitor for your DocuSeal domain
• An alerting setup appropriate for a legally critical system

Prerequisites

• A running DocuSeal instance with a public or network-reachable domain (e.g., https://sign.example.com)
• HTTPS configured with a valid certificate
• A free account at vigilmon.online

Step 1: Understand DocuSeal's Health Signals

DocuSeal is a Rails application. It exposes two external health signals you can monitor without authentication:

Root path (/): Returns HTTP 200 with the DocuSeal login or dashboard page. This confirms the Rails server is running, the web server is forwarding requests, and static assets are being served.

API alive check (/api/submissions): Calling this endpoint without an API key returns HTTP 401 Unauthorized. This is a liveness signal — the 401 response proves that:

• The Rails process is handling requests
• The API router is functioning
• The database is reachable (DocuSeal validates API keys against the database)
• Authentication middleware is loaded

curl -I https://sign.example.com/api/submissions

A healthy DocuSeal returns HTTP 401. Use both signals for comprehensive coverage.

Step 2: Create a Vigilmon Monitor for the Root Path

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://sign.example.com/.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: DocuSeal (or Sign — whatever appears in the page title).
7. Label: DocuSeal Web UI.
8. Click Save.

This monitor catches:

• Rails process crashes or restarts
• Container or VM failures
• Web server (nginx, Caddy) misconfigurations
• Database connection failures at boot time
• Asset pipeline failures that leave the UI partially broken

For a document signing platform used for legally binding agreements, a 60-second polling interval means you know about failures within a minute — well before any scheduled signing session begins.

Step 3: Create a Monitor for the API Alive Check

1. Add Monitor → HTTP.
2. URL: https://sign.example.com/api/submissions.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 401.
6. Label: DocuSeal API Alive.
7. Click Save.

Accepting 401 as "healthy" is correct here — it means DocuSeal received the request, looked up whether the (missing) API key was valid, and correctly rejected the unauthenticated call. A 500 or 503 would mean a real failure; a 401 means DocuSeal is working exactly as designed.

This monitor is particularly valuable because it validates the full request-response cycle through the API layer — the same path your automated document workflows and third-party integrations use. The root path check confirms the web UI is serving; the API check confirms the backend is processing.

Step 4: Monitor SSL Certificates

For a document signing platform, SSL certificate management is business-critical:

• Signatories clicking email links to sign documents will see certificate errors and abandon the signing process rather than trust an insecure page
• Legal admissibility of electronic signatures may depend on the integrity of the signing platform, including TLS security
• Automated integrations sending documents via API will fail certificate validation, breaking your signing workflows silently

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

Important: DocuSeal typically sits behind a reverse proxy (nginx, Caddy, or Traefik). The SSL certificate is managed by the proxy, not DocuSeal itself. A Let's Encrypt certificate that fails to auto-renew will expire silently — the 30-day Vigilmon alert is your safety net if ACME automation stops working.

Step 5: Add a TCP Port Check

Add a TCP check to catch network-layer failures independently of the application:

1. Add Monitor → TCP Port.
2. Host: sign.example.com.
3. Port: 443.
4. Check interval: 5 minutes.
5. Label: DocuSeal TCP 443.
6. Click Save.

If both the HTTP monitor and TCP check fail simultaneously, the problem is at the network or server level (firewall, VM crash, DNS). If only the HTTP monitor fails while TCP succeeds, the problem is in the application layer (Rails crash, bad deployment).

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web UI | Non-200 or keyword missing | Check Rails process; inspect container/service status | | API Alive | Non-401 response | Check database connectivity; inspect Rails logs | | TCP Port | Connection refused | Check firewall rules; verify web server is listening | | SSL Certificate | < 30 days to expiry | Renew immediately; check ACME renewal automation |

Alert after: 1 failure for all monitors — document signing workflows are synchronous operations where a signatory is actively waiting. There's no "let's see if it recovers" window when someone is trying to sign a contract.

Escalation: For SSL certificate alerts, page on-call immediately at the 14-day mark, not just at 30 days. An expired certificate on a signing platform blocks your signatories from completing agreements.

Pre-session checks: For high-stakes signing sessions (investor agreements, employment contracts, legal filings), check DocuSeal's Vigilmon dashboard before the session begins — don't rely solely on reactive alerting for legally time-sensitive work.

Common DocuSeal Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Rails process crash | Root path returns 502; alert within 60 s | | Database connection failure | API alive returns 500 (can't validate auth); alert within 60 s | | Container OOM killed | TCP check fires; HTTP monitors follow | | Reverse proxy misconfiguration | HTTP monitors fire; TCP check may stay green | | SSL certificate expires | SSL monitor alerts at 30-day threshold; signatories see browser errors | | Disk full (storage for PDFs) | DocuSeal may fail to process submissions; logs grow until failure | | Background worker crash | Web UI stays up; email notifications for signing stop sending | | DNS misconfiguration | All HTTP and SSL monitors fire simultaneously | | Bad deployment (migration failure) | Web UI may return 500 after Rails starts | | File storage misconfiguration | Document upload and retrieval fail; UI appears up |

Document signing is one of the few self-hosted applications where downtime has direct legal and financial consequences — a missed signing deadline, a delayed contract, or a failed closing can be measured in real cost. Vigilmon monitors DocuSeal's web UI, API backend, TCP connectivity, and SSL certificate with external checks that are independent of your DocuSeal infrastructure, so availability failures show up in your inbox before your signatories encounter them.

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