Monitoring RSS-Bridge with Vigilmon

RSS-Bridge is an open source PHP application that generates RSS and Atom feeds for websites that don't provide them natively — YouTube channels, Reddit, GitHub releases, Twitter/X, Instagram, and 400+ other "bridges." Each bridge is a PHP class that scrapes a target website and returns XML. When it works, RSS-Bridge is indispensable. When it doesn't — because PHP-FPM crashed, an upstream site changed its structure, or a rate limit kicked in — feeds silently go stale and your RSS reader stops updating without any error message. Vigilmon lets you catch every failure layer: the web server, PHP-FPM process, bridge execution health, and TLS certificate expiry.

What You'll Set Up

• Apache/nginx web server availability and HTTPS monitoring
• PHP-FPM process health monitoring via TCP
• Core bridge execution health checks (via bridge URLs)
• Bridge error rate monitoring via response content checks
• Rate limiting and upstream block detection
• Cache backend accessibility monitoring
• TLS/SSL certificate expiry alerts

Prerequisites

• RSS-Bridge deployed and accessible over HTTP/HTTPS (Apache or nginx + PHP-FPM)
• At least one bridge configured and returning feeds
• A free Vigilmon account

Step 1: Monitor the Web Server Availability

The Apache or nginx server is RSS-Bridge's entry point. If it goes down, no feeds are accessible.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your RSS-Bridge URL: https://rss.yourdomain.com.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Enable Monitor SSL certificate and set Alert when certificate expires in less than 21 days.
7. Click Save.

This catches Apache/nginx crashes, server reboots, firewall changes, and Let's Encrypt renewal failures in one monitor.

Step 2: Monitor PHP-FPM Process Health

RSS-Bridge is a PHP application — PHP-FPM processes every bridge request. If PHP-FPM crashes, nginx returns 502 Bad Gateway errors even though the web server itself is running.

Monitor the PHP-FPM socket/port directly:

If PHP-FPM listens on a TCP port (e.g. 9000):

1. Click Add Monitor → TCP Port.
2. Hostname: localhost (or your PHP-FPM host).
3. Port: 9000.
4. Check interval: 1 minute.
5. Click Save.

If PHP-FPM listens on a Unix socket, add a PHP health endpoint instead. Create a minimal health file at your webroot:

<?php
// /var/www/rss-bridge/health.php
echo json_encode(['status' => 'ok', 'php' => PHP_VERSION]);

Then add an HTTP monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://rss.yourdomain.com/health.php.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

A 502 from the main site with a 200 from health.php means PHP-FPM is alive but RSS-Bridge itself has an error. A 502 on both means PHP-FPM is down.

Step 3: Monitor Core Bridge Execution Health

Each RSS-Bridge bridge scrapes a specific website. Monitor your most critical bridges by fetching their feed URLs directly. A successful feed returns 200 with Content-Type: application/rss+xml or application/atom+xml.

YouTube channel bridge example:

https://rss.yourdomain.com/?action=display&bridge=Youtube&context=By+channel+id&c=UCxxxxxx&format=Atom

1. Click Add Monitor → HTTP / HTTPS.
2. URL: the full bridge URL for a YouTube channel you rely on.
3. Expected HTTP status: 200.
4. Check interval: 15 minutes (bridges that hit external sites shouldn't be probed too frequently — this avoids triggering rate limits on the target site).
5. Click Save.

Add monitors for your 3–5 most critical bridges. Choose channels or accounts with stable content — an empty feed from an inactive source looks identical to a broken bridge.

Step 4: Detect Bridge Errors via Response Content

RSS-Bridge returns HTTP 200 even when a bridge fails — it returns an error message in the feed body (e.g., Could not request website: 429 Too Many Requests). Vigilmon cannot parse XML response bodies, but you can catch the most common failure pattern: PHP fatal errors and bridge exceptions that produce HTML error pages instead of XML feeds.

Add a monitor that checks the Content-Type header indirectly by monitoring for a known-good bridge that reliably returns XML:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: a bridge that returns feeds reliably (e.g., a GitHub releases bridge).
3. Expected HTTP status: 200.
4. Response time threshold: 10000ms — bridge timeouts often cause slow responses before returning an error.
5. Check interval: 15 minutes.
6. Click Save.

For deeper content validation, run a cron job that fetches a bridge URL and pings a Vigilmon heartbeat only when the response contains valid XML:

#!/bin/bash
# /etc/cron.d/rssbridge-bridge-check
RESPONSE=$(curl -s "https://rss.yourdomain.com/?action=display&bridge=Github&context=Releases&u=rss-bridge&r=rss-bridge&format=Atom")
if echo "$RESPONSE" | grep -q '<feed\|<rss'; then
    curl -s https://vigilmon.online/heartbeat/bridge123
fi

1. In Vigilmon, add a Cron Heartbeat monitor with Expected interval 20 minutes.
2. If the bridge stops returning valid XML, the heartbeat stops — Vigilmon alerts.

Step 5: Monitor Cache Backend Health

RSS-Bridge can cache bridge results in SQLite (default) or a custom cache backend. A broken cache causes every bridge request to hit the upstream site directly, burning through rate limits quickly.

For SQLite-backed cache, add a heartbeat from a cron job that verifies the cache file is writable:

#!/bin/bash
# /etc/cron.d/rssbridge-cache-check
CACHE_DIR="/var/www/rss-bridge/cache"
if [ -w "$CACHE_DIR" ] && touch "$CACHE_DIR/.probe" 2>/dev/null; then
    rm -f "$CACHE_DIR/.probe"
    curl -s https://vigilmon.online/heartbeat/cache456
fi

1. In Vigilmon, add a Cron Heartbeat monitor with Expected interval 10 minutes.
2. If the cache directory becomes read-only (full disk, permission change), the heartbeat stops — Vigilmon alerts.

Step 6: Monitor Bridge Response Time

Bridge execution time is an early warning sign. A bridge that normally responds in 2 seconds but starts taking 8–9 seconds is usually hitting upstream rate limits or timeouts before eventually returning an error or empty feed.

Add response time monitoring to your core bridge monitors:

1. Open each bridge monitor created in Step 3.
2. Set Response time alert threshold to 8000ms.
3. Click Save.

When a bridge's response time exceeds 8 seconds consistently, investigate whether the upstream website is rate-limiting your server's IP or has changed its structure.

Step 7: Add SSL Certificate Expiry Monitoring

Already covered in Step 1 for your RSS-Bridge domain, but ensure the certificate alert window is set correctly:

• Alert threshold: 21 days gives you three Let's Encrypt renewal windows (certbot renew runs every 12 hours by default; with 21-day lead time you have 4+ automatic renewal attempts before expiry).

If you've set up a custom domain for RSS-Bridge separate from your main infrastructure, verify the renewal cron is configured:

# Verify certbot renewal cron
systemctl status certbot.timer
# or
crontab -l | grep certbot

Step 8: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Set Consecutive failures before alert to 2 on the main web server monitor to absorb brief Apache/nginx restarts.
3. Set it to 1 on the PHP-FPM TCP monitor — PHP-FPM failures cause immediate 502 errors for all bridge requests.
4. Set it to 1 on the Celery heartbeat — a missed heartbeat means your core bridges have stopped working.
5. Use Maintenance windows during PHP upgrades:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "MONITOR_ID", "duration_minutes": 10}'

Understanding RSS-Bridge's Failure Modes

RSS-Bridge has three distinct failure modes that produce different monitoring signals:

| Failure | HTTP Status | Vigilmon Signal | |---|---|---| | Web server down | Connection refused | HTTP monitor alert | | PHP-FPM crashed | 502 Bad Gateway | HTTP + TCP monitor alert | | Bridge execution error | 200 (with error in body) | Heartbeat stops (Step 4 cron) | | Upstream rate-limited | 200 (slow then error body) | Response time alert | | Cache unwritable | 200 (but slower) | Heartbeat stops (Step 5 cron) |

Distinguishing PHP-FPM failures from bridge execution failures is the key diagnostic insight: if health.php returns 200 but the bridge URL is slow or returning error content, the issue is upstream (rate limit, structural change) not infrastructure.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web server uptime | https://rss.yourdomain.com | Apache/nginx crash, network outage | | PHP-FPM health | TCP localhost:9000 or /health.php | PHP-FPM crash, 502 errors | | Core bridge execution | Bridge feed URLs | Bridge failures, upstream blocks | | Bridge content heartbeat | Cron + heartbeat URL | Invalid XML, bridge exceptions | | Cache backend | Cache write heartbeat | Full disk, permission errors | | Bridge response time | Core bridge monitors | Rate limiting, upstream timeouts | | SSL certificate | rss.yourdomain.com | Let's Encrypt renewal failure |

RSS-Bridge's value — converting the un-feedable web into structured RSS — depends entirely on three layers staying healthy: the PHP runtime, the upstream websites, and the bridge logic itself. With Vigilmon watching the web server, PHP-FPM, core bridge execution, cache health, and response times, you'll catch every failure layer and know whether to restart PHP-FPM, rotate your server IP, or update a bridge's scraping logic.