[Bug] False Radarr "unreachable" status and page load failures on large Radarr libraries

[Timski01]

What happened

Prismarr's Radarr health check (dashboard widget) and the Movies page both call GET /api/v3/movie, which returns the entire library in one response, instead of a lightweight status endpoint. On a library of ~9,800 movies this call takes 22-40+ seconds, well past Prismarr's hardcoded 8-second timeout. Result: the dashboard health widget flaps between "connected" and "unreachable" every few seconds, and the Movies/Radarr page consistently shows "not connected" even though Radarr itself is fully healthy and responsive on every other endpoint.

What you expected to happen

The health check should use a lightweight endpoint (e.g. /api/v3/system/status, confirmed ~2ms response time on this instance) rather than pulling the full library. The Movies page should preferably not depend on an unbounded full-library fetch just to render, given it already has server-side pagination as of v1.1.0.

Steps to reproduce

1. Configure a Radarr instance with a library of ~9,000+ movies in Prismarr's setup wizard
2. Open the Prismarr dashboard and watch the Radarr health indicator — observe it toggling between connected/unreachable every ~20-60 seconds
3. Navigate to the Radarr/Movies page in Prismarr — observe it reports "not connected" despite Radarr being reachable and fast on all other endpoints

Environment

• Prismarr version: v1.1.1
• Docker image digest: shoshuo/prismarr:latest (pulled 2026-08-10)
• Host OS & arch: Unraid 7.3.2, x86_64
• Docker version: 29.5.3 | API version: 1.54 | Go version: go1.26.4
• Reverse proxy: Cloudflare Tunnel (cloudflared), TRUSTED_PROXIES set to Docker bridge subnet

Configured services

• TMDb
• Radarr
• Sonarr
• Prowlarr
• Jellyseerr
• qBittorrent
• Gluetun (status widget not configured, but Radarr/qBittorrent route through it)
• SABnzbd (not listed above but also configured)

Logs

2026-08-10T13:15:42+10:00 [warning] RadarrClient GET /api/v3/movie → HTTP 0 Operation timed out after 8002 milliseconds with 0 bytes received
2026-08-10T12:25:57+10:00 [warning] RadarrClient GET /api/v3/movie → HTTP 0 Operation timed out after 8002 milliseconds with 0 bytes received
2026-08-10T12:26:17+10:00 [warning] RadarrClient GET /api/v3/movie → HTTP 0 Operation timed out after 8002 milliseconds with 0 bytes received
2026-08-10T12:28:29+10:00 [warning] RadarrClient GET /api/v3/movie → HTTP 0 Operation timed out after 8002 milliseconds with 0 bytes received
2026-08-10T12:29:12+10:00 [warning] RadarrClient GET /api/v3/movie → HTTP 0 Operation timed out after 8002 milliseconds with 0 bytes received

Additional diagnostic evidence

Confirmed the timeout is a real Radarr response-time issue, not a Prismarr/network problem, by testing the same call directly from the host and from inside the Prismarr container itself:
$ curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" "http://:7878/api/v3/movie?apikey="
200 40.552489s
(Subsequent tests after Radarr-side database optimization still returned 22.9s-30.5s, consistently over the 8s ceiling.)

Ruled out networking — the lightweight /api/v3/system/status endpoint, same host, same path, returns in ~2ms consistently (15+ consecutive sub-3ms responses, tested from both host and from inside the Prismarr container, zero failures).
Ruled out disk I/O — confirmed the radarr.db is located on an SSD cache drive in the Unraid system.

Confirmed via docker stats that Radarr itself spikes to 73.29% CPU while serving this single request, with all 30+ other containers on the host sitting idle — this is a genuine backend cost of the /api/v3/movie endpoint on Radarr's side (I've filed a separate issue on the Radarr repo for that), but Prismarr's fixed 8s timeout has zero tolerance for libraries at this scale.

Root cause per the v1.1.0 changelog: even though the Movies page has server-side pagination, the changelog states "Facets are computed over the full library" — meaning the page still triggers a full unbounded /api/v3/movie pull server-side before rendering, hitting the same 8s timeout and reporting "not connected" despite Radarr being fully operational.

Suggested fix

• Health check should call /api/v3/system/status instead of /api/v3/movie
• If full library data is genuinely needed for facet computation on the Movies page, consider caching longer, computing facets incrementally/async, or making the timeout configurable per-service for larger libraries
• A per-service configurable timeout (rather than the hardcoded 8002ms) would help other larger installations too

Screenshots