tutorial

Monitoring Stirling-PDF with Vigilmon: Health Endpoint, Web UI, Task Processing & SSL Alerts

How to monitor Stirling-PDF self-hosted document processing with Vigilmon — health endpoint availability, web UI checks, PDF task processing signals, and SSL certificate alerts to keep your document workflows uninterrupted.

Stirling-PDF is the self-hosted PDF manipulation tool that development teams and organisations use to merge, split, compress, convert, OCR, and transform PDF documents — without sending sensitive files to third-party cloud services. It runs as a Spring Boot (Java) application containerised with Docker, exposing a web interface and REST API for document operations. When Stirling-PDF goes down, document workflows stall: automated PDF pipelines break, team members can't process documents, and integrations that depend on its API start failing silently. Vigilmon gives you external visibility into Stirling-PDF's health endpoint, web UI availability, task processing signals, and SSL certificate so you're notified the moment your document processing service becomes unreachable.

What You'll Build

  • An HTTP monitor for Stirling-PDF web UI availability
  • A liveness check on the Stirling-PDF health endpoint
  • SSL certificate monitoring for your Stirling-PDF domain

Prerequisites

  • A running Stirling-PDF instance with a public or network-reachable domain
  • HTTPS configured via a reverse proxy (e.g., https://pdf.example.com)
  • A free account at vigilmon.online

Step 1: Verify Stirling-PDF Web UI Availability

Stirling-PDF serves its tool dashboard from the root path. A successful response confirms the Spring Boot application is running and the reverse proxy is routing traffic correctly:

curl -I https://pdf.example.com
# Expected: HTTP/2 200

The root path returns the Stirling-PDF home dashboard with its tool selection interface. A 200 response confirms the Java application is running and able to serve content. This is your primary availability signal — if it fails, no document operations can be performed through either the web interface or the API.

Step 2: Create a Vigilmon HTTP Monitor for Web UI Availability

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://pdf.example.com.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Stirling.
  7. Label: Stirling-PDF Web UI.
  8. Click Save.

This monitor catches:

  • Spring Boot JVM crashes or container restarts
  • Out-of-memory kills (PDF processing is memory-intensive; large documents can exhaust heap)
  • Reverse proxy misconfigurations blocking access to the service
  • Configuration errors after upgrades that prevent the application from starting
  • Port mapping failures in Docker that cause the service to be unreachable

When this monitor fires, all web-based PDF operations and API calls become unavailable. Any automated pipelines that submit documents via the REST API will start failing immediately.

Step 3: Monitor the Health Endpoint

Stirling-PDF exposes a Spring Boot Actuator health endpoint that confirms the application is running and reporting healthy status:

curl https://pdf.example.com/api/v1/info/status
# Expected: HTTP 200

A typical response:

{"status": "UP"}

This confirms the Spring Boot application is running and the Actuator health check is passing.

  1. Add Monitor → HTTP.
  2. URL: https://pdf.example.com/api/v1/info/status.
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: UP.
  6. Label: Stirling-PDF Health.
  7. Click Save.

Why monitor the health endpoint separately? The web dashboard requires rendering a full HTML response with tool listings, whereas the Actuator health endpoint is a lightweight JSON probe. If the application is in a degraded state — low memory, a hung thread, or an initialisation problem — the health endpoint may respond while the dashboard times out. The two signals together let you distinguish a fully healthy service from a degraded one.

Step 4: Monitor PDF Task Processing

Stirling-PDF's core value is its ability to process document operations — merging PDFs, extracting pages, running OCR, converting formats. A service that's reachable at the health endpoint but failing to complete PDF operations is only superficially healthy.

Use Vigilmon's cron heartbeat monitor to verify that processing is working end-to-end:

  1. Create a lightweight test script that submits a small PDF operation to Stirling-PDF's API and, on success, pings a Vigilmon heartbeat:
#!/bin/bash
# Submit a minimal PDF info request to Stirling-PDF API
RESULT=$(curl -sf -X POST \
  -F "fileInput=@/path/to/test.pdf" \
  "https://pdf.example.com/api/v1/misc/get-info-on-pdf")

if echo "$RESULT" | grep -q "PDF"; then
  curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_URL
fi
  1. Schedule this script as a cron job (e.g., every 10 minutes):
*/10 * * * * /usr/local/bin/check-stirling-pdf.sh
  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 10 minutes.

If Stirling-PDF's processing pipeline stalls (GhostScript failure, LibreOffice unavailable, temp directory full), the heartbeat stops arriving and Vigilmon alerts you before users start reporting failed document operations.

Step 5: Monitor SSL Certificates

Stirling-PDF handles sensitive documents — legal contracts, financial reports, internal design files. HTTPS is the only thing preventing document content from being exposed in transit. A certificate expiry:

  • Blocks all browser access with certificate error pages
  • Breaks all API integrations that submit documents programmatically
  • Fails automated pipelines that use Stirling-PDF as a processing step
  1. Add Monitor → SSL Certificate.
  2. Domain: pdf.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web UI | Non-200 or keyword missing | Check Spring Boot container; inspect JVM heap; verify reverse proxy | | Health Endpoint | Non-200 or UP missing | Check application status; inspect Actuator logs; verify container health | | Processing Heartbeat | Heartbeat missing | Check GhostScript/LibreOffice availability; inspect temp directory; review processing logs | | SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is running |

Alert after: 2 consecutive failures for HTTP monitors — PDF processing services can have occasional slow responses under load; two consecutive failures reliably indicate a real problem.

Common Stirling-PDF Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | JVM out-of-memory kill | Container restarts; both HTTP monitors fire | | Spring Boot startup failure | Web UI and health monitors fire; container may loop | | GhostScript unavailable | PDF operations fail; processing heartbeat stops | | LibreOffice crash (format conversions) | Conversion operations fail; heartbeat stops | | Temp directory full | File processing fails; heartbeat stops; uploads return errors | | Reverse proxy misconfiguration | Web UI fires; application container remains healthy | | SSL certificate expires | SSL monitor alerts at 30 days; all access breaks | | Container image update breaks configuration | Application fails to start; both HTTP monitors fire | | Network storage unavailable | File upload/download operations fail; heartbeat stops |

Stirling-PDF is the processing engine for your team's document workflows — when it's down, every PDF operation queued against it fails. Vigilmon watches the web UI, health endpoint, processing pipeline, and SSL certificate so you're alerted within 60 seconds of any failure, before your users start reporting that document operations aren't working.

Start monitoring Stirling-PDF 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