Monitoring Zipline with Vigilmon: Upload Server Health, PostgreSQL, and Storage Alerts

Zipline is a self-hosted file upload and sharing server built for ShareX, supporting images, videos, documents, and arbitrary files. It comes with a polished dashboard, user management, URL shortening, and support for both local disk and S3-compatible object storage — all backed by a PostgreSQL database. It's increasingly popular as a self-hosted alternative to Imgur, i.imgur, and other managed file hosts. But when you self-host, you become the SRE. If Zipline's Node.js process crashes, PostgreSQL goes down, or your S3 bucket becomes unreachable, uploads fail silently and shared links return 404s. Vigilmon gives you external monitoring that watches every critical layer of Zipline and alerts you before your users notice.

What You'll Build

• A Vigilmon HTTP monitor on Zipline's /api/health endpoint
• A dashboard availability check to confirm the UI is rendering
• PostgreSQL connectivity monitoring via the health API response
• Storage availability detection (S3 or local disk)
• SSL certificate alerts if proxied

Prerequisites

• A running Zipline instance accessible over HTTPS (recommended: reverse proxy with Caddy or Nginx)
• A free account at vigilmon.online

Step 1: Verify Zipline's Health Endpoint

Zipline exposes a health check endpoint at /api/health. It performs an internal database connectivity check and returns a structured JSON response.

curl https://your-zipline-domain.com/api/health

A healthy Zipline returns something like:

{"ok": true}

If PostgreSQL is unreachable or the Zipline process is degraded, the endpoint returns a non-200 response or {"ok": false}. If the process has crashed entirely, the connection is refused.

TLS setup: Zipline runs on :3000 by default. Front it with Caddy for automatic HTTPS:

zipline.yourdomain.com {
  reverse_proxy localhost:3000
}

Step 2: Create an HTTP Monitor for /api/health

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://your-zipline-domain.com/api/health.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: true (matches {"ok": true}).
7. Click Save.

The keyword assertion is critical: it rejects responses where the HTTP layer returns 200 but the body signals a degraded state. A proxy intercepting a crashed Zipline often returns a 200 error page — the keyword check catches this where a status-only check wouldn't.

Step 3: Monitor the Dashboard UI

The /api/health endpoint confirms Zipline's backend is healthy, but it doesn't verify that the Next.js dashboard is rendering. Add a second monitor on the root URL:

1. Add Monitor → HTTP.
2. URL: https://your-zipline-domain.com/.
3. Expected status: 200.
4. Keyword: Zipline (appears in the page title).
5. Check interval: 5 minutes (the UI changes less frequently than the API).
6. Click Save.

This catches Next.js build failures, missing environment variables that break SSR, or static asset serving problems that leave the API functional but the dashboard blank.

Step 4: Detect PostgreSQL Issues

Zipline's /api/health endpoint internally checks database connectivity before responding. When PostgreSQL becomes unavailable — due to a crashed postgres process, OOM kill, or network partition — Zipline's health endpoint returns a non-200 response within seconds.

Your Step 2 monitor covers this automatically. To verify the mechanism:

# Simulate a PostgreSQL failure locally to confirm Vigilmon would catch it
sudo systemctl stop postgresql
curl https://your-zipline-domain.com/api/health
# Should return non-200 or {"ok": false}
sudo systemctl start postgresql

For more visibility, add a PostgreSQL-level TCP monitor:

1. Add Monitor → Port (TCP).
2. Host: your database host (localhost or an internal IP if separate).
3. Port: 5432.
4. Note: Only do this if PostgreSQL is on a host Vigilmon can reach. For localhost-only databases, rely on the /api/health endpoint which wraps the database check.

Step 5: Monitor Storage Availability

Zipline supports two storage backends: local disk and S3-compatible object storage (AWS S3, MinIO, Backblaze B2, etc.). Storage failures are distinct from application failures — Zipline can be fully healthy while uploads fail because the storage backend is unreachable.

For local disk storage: Add a heartbeat monitor that pings Vigilmon only when disk usage is below threshold.

# /etc/cron.d/zipline-storage-heartbeat
*/5 * * * * root \
  DISK=$(df /opt/zipline/uploads --output=pcent | tail -1 | tr -d '% ') && \
  [ "$DISK" -lt 85 ] && \
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID

Create a Heartbeat monitor in Vigilmon with a 10-minute grace period. If disk usage exceeds 85%, the cron stops pinging, and Vigilmon alerts you before uploads start failing.

For S3 storage: Monitor your S3 bucket's endpoint directly if it's publicly accessible, or use the heartbeat approach above triggered by a test upload script.

Step 6: SSL Certificate Alerts

Zipline serves user-uploaded content over HTTPS. An expired certificate doesn't just break the dashboard — it invalidates every shared file link and image embed. This is a high-impact failure.

Configure aggressive SSL monitoring:

1. Open any HTTPS monitor → SSL Certificate.
2. Alert threshold: 21 days before expiry (more lead time than usual given the link-invalidation impact).
3. Add a 30-day advance alert.

If you've configured a custom domain for uploads (e.g., cdn.yourdomain.com served separately), add a dedicated HTTPS monitor for that domain too.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications:

| Trigger | Recommended action | |---|---| | /api/health non-200 or keyword missing | Email + Slack; check pm2 logs zipline or journalctl -u zipline | | Dashboard keyword Zipline missing | Email; Next.js SSR failure; rebuild or restart process | | TCP 5432 unreachable | Email; restart PostgreSQL; check journalctl -u postgresql | | Disk heartbeat missed | Email; SSH in and run df -h /opt/zipline/uploads | | SSL certificate < 21 days | Email; verify Caddy auto-HTTPS or run certbot renew |

Alert after: 1 consecutive failure. Zipline is a production file server; delays cost you user trust and broken embeds.

Re-notify: every 5 minutes while down. A broken file host with broken shared links degrades quickly.

What Vigilmon Catches That Zipline Logs Miss

| Scenario | Zipline logs | Vigilmon | |---|---|---| | Node.js process OOM-killed | Kernel log only | HTTP monitor fires within 60–120 s | | PostgreSQL crash | Error in Zipline log | /api/health fails; Vigilmon alerts immediately | | Upload disk full | Errors on write | Heartbeat misses; Vigilmon alerts before disk fills | | S3 bucket policy change blocks uploads | Per-upload errors | Heartbeat or storage check catches it | | SSL certificate expires | Not logged by Zipline | SSL monitor alerts 21 days early | | VPS network partition | Inaccessible logs | External Vigilmon probe still running |

Zipline handles files your users are actively sharing — broken links, failed uploads, and missing images are immediately visible failures that damage trust. Vigilmon catches the infrastructure problems before they surface as user complaints.

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