tutorial

Monitoring Stump with Vigilmon: Uptime & Health Alerts for Your Self-Hosted Comic Server

How to monitor a self-hosted Stump comic book and manga server with Vigilmon — using the built-in ping endpoint, HTTP monitors, keyword assertions, and SSL certificate alerts for Rust-based self-hosted servers.

Stump is a self-hosted, open-source comic book, manga, and PDF server written in Rust. It's fast, efficient, and runs comfortably on low-powered hardware — but self-hosting means you're responsible for keeping it online. If the Stump process crashes, its SQLite database becomes corrupted, or your library files become inaccessible, there's nothing to notify you. Vigilmon provides external uptime monitoring that watches your Stump server from outside your network and alerts you the moment something goes wrong — before your reading session reveals the problem.

What You'll Build

  • A Vigilmon HTTP monitor on Stump's /api/v1/ping health endpoint
  • A keyword assertion to verify the API is genuinely responding
  • A secondary monitor for the Stump web UI
  • SSL certificate alerts for proxied deployments

Prerequisites

  • A running Stump instance (default port: 10801)
  • A reverse proxy (Caddy or Nginx) with HTTPS — required for Vigilmon monitors
  • A free account at vigilmon.online

Step 1: Locate Stump's Health Endpoint

Stump's REST API includes a ping endpoint at /api/v1/ping. It's available on every Stump installation without authentication:

curl http://localhost:10801/api/v1/ping

A healthy Stump server returns HTTP 200 with a JSON body confirming the server is running. If the Rust process has panicked or the HTTP listener has stopped, you'll get a connection refused error instead.

HTTPS first: Vigilmon requires HTTPS. Proxy Stump with Caddy for automatic certificate management:

stump.yourdomain.com {
  reverse_proxy localhost:10801
}

Step 2: Create a Vigilmon HTTP Monitor

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://stump.yourdomain.com/api/v1/ping.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds (Stump's Rust core is fast — 10 s is very generous).
  5. Expected status: 200.
  6. Click Save.

Vigilmon immediately begins probing your Stump health endpoint from an external location every 60 seconds. If the server stops responding — for any reason — you'll receive an alert within 1–2 minutes.

Step 3: Add a Keyword Assertion

The ping endpoint confirms the HTTP layer is responding, but a keyword assertion verifies the response body is correct — ruling out proxy error pages that return 200 with an HTML error body.

In the monitor settings, add a Keyword assertion:

  • Keyword: pong (Stump's ping response typically includes this)
  • Keyword must be present: yes

This catches cases where Nginx returns a 200 "upstream unavailable" page while Stump itself is down, or where the server is responding but returning an unexpected body during a partial startup.

Step 4: Monitor the Web UI

The ping endpoint checks the API layer, but the Stump web UI is what you actually interact with. Add a second monitor to verify the frontend is serving correctly:

  1. Add Monitor → HTTP.
  2. URL: https://stump.yourdomain.com/ (the web UI root).
  3. Expected status: 200.
  4. Keyword: Stump (appears in the HTML page title).
  5. Check interval: 5 minutes (less critical than the API health check).

This monitor catches cases where the Stump backend API is up but the frontend assets aren't being served correctly — for example, after an incomplete upgrade or a misconfigured static file path.

Step 5: Monitor Database Connectivity Indirectly

Stump uses SQLite as its database. If the SQLite file becomes corrupted or the disk fills up, Stump will return errors on database-dependent API calls even though the server process itself is still running. The API /api/v1/ping endpoint may not exercise the database directly.

For database-backed health verification, you can monitor a lightweight authenticated endpoint that queries the library:

# Verify Stump can query its library (requires auth token)
curl -H "Authorization: Bearer YOUR-TOKEN" \
  https://stump.yourdomain.com/api/v1/libraries

Add a heartbeat monitor to verify Stump can serve library data:

  1. Add Monitor → Heartbeat.
  2. Expected interval: 1 hour.
  3. Grace period: 15 minutes.

Configure a cron job on your server to call this endpoint and POST to the heartbeat URL if the response is successful:

*/30 * * * * root \
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer YOUR-TOKEN" \
    https://stump.yourdomain.com/api/v1/libraries) && \
  [ "$STATUS" = "200" ] && \
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID

If the database becomes inaccessible, the library endpoint starts failing, the heartbeat stops, and Vigilmon alerts you.

Step 6: Monitor SSL Certificate Expiry

When running Stump behind a reverse proxy with HTTPS, certificate expiry silently locks users out. Vigilmon automatically monitors the SSL certificate of any HTTPS monitor URL.

In your existing HTTP monitor settings:

  • SSL certificate alert: enable it.
  • Alert days before expiry: 14 days.

Even with auto-renewal via Certbot or Caddy, renewal failures are silent until the certificate actually expires. Vigilmon's alert gives you a 14-day window to investigate and fix renewal issues before they cause downtime.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up your alert channels:

| Trigger | Action | |---|---| | /api/v1/ping non-200 | Email — check systemctl status stump | | Response timeout | Email — Stump process may be hung; consider restart | | Keyword missing | Email — reverse proxy misconfiguration | | Heartbeat missed | Email — SQLite or filesystem issue; check df -h and Stump logs | | SSL expiry < 14 days | Email — force certificate renewal immediately |

Alert after: 1 consecutive failure for the ping endpoint (Stump is single-process and stable).

Re-notify: every 15 minutes while the issue persists.

Keeping Stump Running with systemd

Run Stump as a systemd service so it auto-restarts on crash:

# /etc/systemd/system/stump.service
[Unit]
Description=Stump Comic Server
After=network.target

[Service]
Type=simple
User=stump
WorkingDirectory=/opt/stump
ExecStart=/opt/stump/stump
Restart=always
RestartSec=5
Environment=STUMP_PORT=10801

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now stump

With systemd auto-restart and Vigilmon external monitoring, your coverage chain is:

  1. Stump crashes → systemd restarts within 5 seconds
  2. If it doesn't come back, Vigilmon detects the outage within 60–120 seconds and alerts you
  3. You SSH in and check journalctl -u stump -n 50

What Vigilmon Catches That Stump Logs Miss

| Scenario | Stump logs | Vigilmon | |---|---|---| | Process crash, systemd restart fails | Crash logged, then silent | HTTP monitor fires within 60–120 s | | SQLite corruption → API errors | Rust panic in logs | Heartbeat stops arriving | | Disk full → library scan failures | Write error in logs | Heartbeat stops arriving | | SSL certificate expires | Not monitored | Certificate expiry alert fires | | Web UI assets broken after upgrade | Not in API logs | Keyword monitor on UI catches it |

Stump's Rust foundation makes it reliable, but no process runs forever without monitoring. Vigilmon gives your comic server the same external health checks that production systems take for granted.

Start monitoring your Stump instance 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