Monitoring FlareSolverr with Vigilmon

FlareSolverr is the unsung backbone of many homelab media stacks. Prowlarr, Jackett, and torrent indexer scrapers route through it to bypass Cloudflare's bot protection — meaning when FlareSolverr goes down or degrades, your entire automated media acquisition pipeline silently stalls. No new releases get grabbed. Sonarr and Radarr queue up but never find anything. And you usually don't notice until days later when you wonder why nothing downloaded.

Vigilmon gives you the monitoring layer FlareSolverr lacks out of the box: availability alerts, response time tracking, and heartbeat checks that catch silent degradation before it ruins your media weekend.

What You'll Set Up

• HTTP API availability monitoring (/health endpoint)
• Main proxy endpoint responsiveness check (/v1)
• Response time monitoring for challenge-solving latency
• Memory usage heartbeat for Chrome OOM detection
• Concurrent session health via cron heartbeat
• TLS certificate expiry for reverse-proxy setups

Prerequisites

• FlareSolverr running (Docker or bare-metal, default port 8191)
• FlareSolverr accessible from your monitoring host (direct or via reverse proxy)
• A free Vigilmon account

Step 1: Monitor the FlareSolverr Health Endpoint

FlareSolverr exposes a built-in health endpoint at GET /health. This is the fastest and most reliable way to confirm the HTTP server is alive and the service process is running.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your FlareSolverr URL: http://flaresolverr.yourdomain.com:8191/health
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

A healthy response looks like:

{"status": "ok", "version": "v3.x.x", "userAgent": "..."}

If you run FlareSolverr behind a reverse proxy (Nginx Proxy Manager, Caddy, Traefik), use the HTTPS URL instead:

https://flaresolverr.yourdomain.com/health

Step 2: Monitor the Main Proxy Endpoint Liveness

The /health endpoint only confirms the HTTP server is up — it does not validate that FlareSolverr can actually launch a headless Chrome instance and process requests. To catch deeper failures (Chromium binary missing, X virtual framebuffer issues, Chrome crashes), monitor the /v1 endpoint with a lightweight probe.

FlareSolverr's /v1 endpoint returns 405 Method Not Allowed for GET requests (it expects POST). Use this to verify the endpoint is routing correctly without triggering a real Cloudflare solve:

1. Add a new monitor in Vigilmon.
2. Set Type to HTTP / HTTPS.
3. URL: http://flaresolverr.yourdomain.com:8191/v1
4. Expected HTTP status: 405
5. Check interval: 2 minutes
6. Click Save.

A 404 or connection refused means the routing layer has broken. A 500 error can indicate Chrome initialization failure.

Step 3: Monitor FlareSolverr Response Times

Cloudflare challenge solving is inherently slow — expect 5–15 seconds per solve. But if response times balloon to 30+ seconds or P95 latency spikes, it usually means:

• Cloudflare has updated its bot detection and FlareSolverr is struggling
• Chrome instances are accumulating and slowing the host
• The host is under memory pressure (OOM kill risk)

Vigilmon automatically tracks response time for every HTTP monitor. After adding the /health monitor in Step 1:

1. Navigate to the monitor in Vigilmon.
2. Open the Response Time chart.
3. Set an alert threshold: if response time exceeds 5000ms (5 seconds) for the /health endpoint, something is wrong at the process level.

Why 5s for /health? The health endpoint should respond in milliseconds — it is just a JSON status return. If even the health endpoint is slow, the process is overloaded.

Step 4: Set Up a Memory Usage Heartbeat

Chrome instances are memory-intensive. On a 2 GB RAM host, four concurrent Chrome sessions can trigger OOM kills, causing FlareSolverr to silently lose the ability to spawn new sessions without the process itself crashing.

Create a cron heartbeat that checks FlareSolverr's memory footprint and only fires the Vigilmon heartbeat if memory is within safe bounds:

1. In Vigilmon, go to Add Monitor → Cron / Heartbeat.
2. Set the expected interval to 5 minutes.
3. Copy the heartbeat ping URL (e.g., https://vigilmon.online/api/heartbeat/YOUR_TOKEN).

Then on your FlareSolverr host, add a cron job:

# /etc/cron.d/flaresolverr-mem-check
*/5 * * * * root \
  CHROME_MEM=$(ps aux | grep chrome | grep -v grep | awk '{sum+=$6} END {print sum}') && \
  [ "${CHROME_MEM:-0}" -lt 1500000 ] && \
  curl -fsS "https://vigilmon.online/api/heartbeat/YOUR_TOKEN" > /dev/null

This script sums the RSS memory of all Chrome processes (in KB). If Chrome processes consume more than ~1.5 GB (adjust to your host's RAM), the heartbeat stops firing and Vigilmon alerts you before the OOM killer strikes.

Step 5: Monitor Concurrent Session Health

FlareSolverr has a configurable maximum concurrent sessions (default: 1, configurable via MAX_TIMEOUT and session management). When the session pool is exhausted, new requests queue indefinitely. Create a simple availability check that mimics what Prowlarr does:

Add a second cron heartbeat that runs a test solve request and only fires if FlareSolverr responds within a reasonable time:

# /etc/cron.d/flaresolverr-session-check
*/10 * * * * root \
  RESULT=$(curl -fsS -o /dev/null -w "%{http_code}" -X POST \
    http://localhost:8191/v1 \
    -H "Content-Type: application/json" \
    -d '{"cmd":"sessions.list"}' \
    --max-time 10) && \
  [ "$RESULT" = "200" ] && \
  curl -fsS "https://vigilmon.online/api/heartbeat/YOUR_SESSION_TOKEN" > /dev/null

The sessions.list command is a lightweight internal FlareSolverr command that does not spawn Chrome. If it fails, the request routing layer itself has broken.

Step 6: Configure TLS Certificate Monitoring (Reverse Proxy Setup)

If FlareSolverr is exposed behind a reverse proxy with TLS (recommended for any setup where FlareSolverr is not strictly localhost-only), add certificate monitoring:

1. Add an SSL Certificate monitor in Vigilmon.
2. Domain: flaresolverr.yourdomain.com
3. Alert threshold: 14 days before expiry.
4. Click Save.

An expired certificate causes Prowlarr and other clients to reject FlareSolverr connections with TLS errors — silent from FlareSolverr's perspective, immediately breaking the entire *arr stack.

Step 7: Configure Alerting

FlareSolverr failures are silent failures — your media stack keeps trying, looks healthy, but nothing actually works. Fast alerts matter.

1. In Vigilmon, navigate to Alert Settings.
2. Add email alerts for all FlareSolverr monitors: immediate notification on first failure.
3. Add a webhook to your homelab chat (Discord, Mattermost, Ntfy) so you get a push notification on your phone.
4. For the memory heartbeat, set missed heartbeat alert to trigger after 1 missed check (10 minutes) — Chrome OOM situations escalate quickly.

Troubleshooting Common FlareSolverr Failures

| Symptom | Likely Cause | Action | |---|---|---| | /health returns 200 but Prowlarr errors | Cloudflare updated bot detection | Update FlareSolverr to latest version | | /v1 returns 500 | Chrome binary missing or Xvfb crash | Restart container; check Docker logs | | Response times > 30s | Chrome accumulation / memory pressure | Restart FlareSolverr; increase host RAM | | Memory heartbeat stops | Chrome OOM risk | Restart and reduce MAX_TIMEOUT | | Session check fails | Session pool exhausted | Restart and check MAX_TIMEOUT config |

Summary: Full FlareSolverr Monitoring Coverage

| Monitor | URL / Target | Expected | Interval | |---|---|---|---| | Health endpoint | http://host:8191/health | 200 | 1 min | | Proxy endpoint liveness | http://host:8191/v1 | 405 | 2 min | | Memory heartbeat | Cron → heartbeat URL | Heartbeat | 5 min | | Session health heartbeat | Cron → heartbeat URL | Heartbeat | 10 min | | TLS Certificate | flaresolverr.domain | 14-day alert | daily |

Conclusion

FlareSolverr is a critical but invisible dependency in any automated media homelab. Without monitoring, you discover it's broken when your watchlist stops populating — not when it actually fails. A five-minute Vigilmon setup gives you immediate alerts for process crashes, Chrome memory pressure, and certificate expiry, keeping your *arr stack running reliably.

Start monitoring FlareSolverr for free at Vigilmon →