Monitoring XBackbone with Vigilmon

XBackbone is a self-hosted file manager and media sharing platform built in PHP, tightly integrated with the ShareX screen capture tool. Running on port 80 (or behind a reverse proxy), it handles file uploads, thumbnail generation, database metadata storage, and ShareX custom uploader destinations. When PHP-FPM crashes, the database connection drops, or the storage backend runs out of space, uploads fail silently and ShareX users get confusing error responses. Vigilmon provides the uptime monitoring layer XBackbone lacks out of the box, so you know about failures before your users do.

What You'll Set Up

• Web application availability monitor (port 80)
• PHP-FPM process health probe
• File upload API endpoint monitor
• ShareX upload destination health check
• Database connectivity probe
• Thumbnail generation service monitor
• Storage backend availability check

Prerequisites

• XBackbone running and accessible on port 80 (or your configured port)
• PHP-FPM configured and serving XBackbone
• A free Vigilmon account

Step 1: Monitor the XBackbone Web Application

The main web UI confirms PHP-FPM is processing requests and XBackbone's front-end routes are operational:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your XBackbone URL: http://YOUR_SERVER_IP or https://YOUR_DOMAIN.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Response body contains, enter XBackbone or the title of your installation to confirm the correct application is responding.
7. Click Save.

A 502 Bad Gateway response instead of 200 typically indicates PHP-FPM has crashed or nginx cannot connect to the FastCGI socket. A 500 response suggests a PHP application error — check the XBackbone logs at storage/logs/.

Step 2: Monitor PHP-FPM Process Health

PHP-FPM is the process manager that handles all PHP execution for XBackbone. If it crashes or exhausts its worker pool, all HTTP requests queue and eventually return 502 errors. Monitor the PHP-FPM status endpoint:

First, enable the PHP-FPM status page in your pool configuration (/etc/php/8.x/fpm/pool.d/www.conf):

pm.status_path = /fpm-status

Then expose it in your nginx config (restrict to localhost or a trusted IP):

location /fpm-status {
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/var/run/php/php8.x-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Then in Vigilmon:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://YOUR_SERVER_IP/fpm-status.
3. Set Expected HTTP status to 200.
4. Under Response body contains, enter pool: to confirm the status page is rendering.
5. Set Check interval to 1 minute.
6. Click Save.

If PHP-FPM status is not accessible externally, use a cron heartbeat that runs the check from the server itself:

#!/bin/bash
STATUS=$(curl -s http://127.0.0.1/fpm-status)
if echo "$STATUS" | grep -q "pool:"; then
  curl -s https://vigilmon.online/heartbeat/YOUR_FPM_HEARTBEAT_ID
fi

Step 3: Monitor the File Upload API Endpoint

XBackbone receives file uploads via a POST endpoint. Confirm this route is reachable and not blocked by a misconfigured proxy or PHP error:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the upload endpoint: http://YOUR_SERVER_IP/upload.
3. Set Method to GET.
4. Set Expected HTTP status to 200 or 405 — a 405 Method Not Allowed for a GET on an upload endpoint confirms the route is registered and the application is handling requests. A 404 indicates the route is broken.
5. Set Check interval to 2 minutes.
6. Click Save.

For a more robust check, use the XBackbone API to perform a token-authenticated probe:

#!/bin/bash
# Probe XBackbone upload route with a small test file
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://YOUR_SERVER_IP/upload \
  -H "token: YOUR_UPLOAD_TOKEN" \
  -F "file=@/dev/null;filename=probe.txt;type=text/plain")

# 200 = success, 400 = validation error (both confirm route is active)
if [ "$RESPONSE" -eq 200 ] || [ "$RESPONSE" -eq 400 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_UPLOAD_HEARTBEAT_ID
fi

Step 4: Monitor the ShareX Upload Destination

ShareX uses XBackbone as a custom uploader destination. If XBackbone changes its upload token validation or the /upload endpoint breaks, all ShareX uploads fail with network errors. Validate the ShareX-facing path specifically:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://YOUR_SERVER_IP/upload (the same route ShareX POSTs to).
3. Set Expected HTTP status to 200 or 302.
4. Under Custom Headers, add token: YOUR_UPLOAD_TOKEN.
5. Set Check interval to 5 minutes.
6. Click Save.

Note: XBackbone's upload endpoint requires a valid token. Create a dedicated monitoring token in XBackbone's admin panel (Tokens section) with a descriptive label like "Vigilmon probe" so you can track its usage separately from real upload tokens.

Step 5: Monitor Database Connectivity

XBackbone stores file metadata, user accounts, and media information in SQLite or MySQL/MariaDB. If the database becomes unavailable, uploads appear to succeed but metadata is lost and the media gallery returns errors:

For SQLite (default), monitor the database file's accessibility from the application layer. Check the XBackbone admin panel endpoint which queries the database:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://YOUR_SERVER_IP/admin (requires authentication).
3. Set Expected HTTP status to 200 or 302 (redirect to login).
4. Set Check interval to 5 minutes.
5. Click Save.

For MySQL/MariaDB, set up a server-side database connectivity probe:

#!/bin/bash
# Test MySQL connectivity used by XBackbone
mysql -u xbackbone_user -pYOUR_PASSWORD -h localhost xbackbone_db \
  -e "SELECT 1" --silent 2>/dev/null

if [ $? -eq 0 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_DB_HEARTBEAT_ID
fi

Add a Cron Heartbeat in Vigilmon with a 5-minute interval for this probe.

Step 6: Monitor Thumbnail Generation Service

XBackbone generates thumbnails for uploaded images and videos. Thumbnail generation failures are invisible in the UI — files upload successfully but previews are broken or missing. Monitor this via the storage path for generated thumbnails:

#!/bin/bash
# Check that the thumbnails directory is writable
THUMB_DIR="/path/to/xbackbone/storage/thumbnails"
TEST_FILE="$THUMB_DIR/.vigilmon-probe"

touch "$TEST_FILE" 2>/dev/null && rm "$TEST_FILE" 2>/dev/null

if [ $? -eq 0 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_THUMBNAIL_HEARTBEAT_ID
fi

Also verify thumbnail generation is not blocked by a missing GD or Imagick PHP extension:

#!/bin/bash
# Test PHP GD availability (required for XBackbone thumbnails)
php -r "if (extension_loaded('gd')) { exit(0); } else { exit(1); }" 2>/dev/null

if [ $? -eq 0 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_GD_HEARTBEAT_ID
fi

Add Cron Heartbeat monitors in Vigilmon for each probe with a 15-minute interval.

Step 7: Monitor Storage Backend Availability

XBackbone stores uploaded files on the local filesystem or in an S3-compatible bucket (via the Flysystem adapter). Storage saturation causes uploads to fail at the write layer without surfacing a clear error to the user:

Local filesystem:

#!/bin/bash
# Check storage directory disk usage
STORAGE_DIR="/path/to/xbackbone/storage/uploads"
USAGE=$(df "$STORAGE_DIR" | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$USAGE" -lt 85 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_DISK_HEARTBEAT_ID
fi

S3-compatible storage:

#!/bin/bash
# Test S3 write and read access
TEST_KEY="xbackbone-probe-$(date +%s)"
aws s3 cp /dev/stdin "s3://YOUR_BUCKET/$TEST_KEY" \
  --content-type text/plain --quiet <<< "probe" 2>/dev/null \
  && aws s3 rm "s3://YOUR_BUCKET/$TEST_KEY" --quiet 2>/dev/null

if [ $? -eq 0 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_S3_HEARTBEAT_ID
fi

Add Cron Heartbeat monitors with a 15-minute interval for each storage probe.

Step 8: Configure Alerts and Maintenance Windows

1. Go to Alert Channels in Vigilmon and add email, Slack, or a webhook endpoint.
2. For the web application and PHP-FPM monitors, set Consecutive failures before alert to 1 — PHP-FPM crashes result in immediate 502 errors for all users.
3. For storage and thumbnail monitors, set to 2 to avoid false alerts from brief I/O spikes.
4. Use Maintenance windows during XBackbone updates:

# Open a 10-minute maintenance window
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 10}'

# Update XBackbone
cd /path/to/xbackbone && composer install --no-dev
php bin/migrate --no-interaction

# Restart PHP-FPM
systemctl restart php8.x-fpm

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web application | http://HOST | PHP-FPM crash, nginx misconfiguration | | PHP-FPM status | /fpm-status | Worker pool exhaustion, FPM crash | | Upload API | POST /upload | Upload route broken, middleware error | | ShareX destination | Authenticated upload probe | Token validation failure | | Database | Admin panel or MySQL probe | DB connection loss, corrupted SQLite | | Thumbnail service | Heartbeat URL | GD extension missing, thumbnails dir unwritable | | Storage backend | Heartbeat URL | Disk full, S3 credentials expired |

XBackbone makes self-hosted media sharing simple — but PHP's failure modes are notoriously silent, and storage problems only surface when users try to upload. With Vigilmon watching the full stack from PHP-FPM through database connectivity and storage health, you catch infrastructure failures before they become user-facing errors.