Prowlarr Indexer Scoring

When Prowlarr is enabled, Inspectarr scores each of your torrent indexers by health, automatically reorders them so the best ones are searched first, and tracks how many torrents each indexer has served and how many turned out to be malicious. NZB indexers are left alone.

This is optional — Inspectarr's core detection works without Prowlarr. Scoring just adds a feedback loop that demotes indexers serving slow, failing, or malicious results.

---

The health score

Each torrent indexer gets a 0–100% health score from four factors:

Factor	What it measures	Default weight
Response time	Rolling average query response time (faster is better)	0.35
Failure rate	Share of successful queries in the history window	0.40
Malicious hits	How many torrents from this indexer Inspectarr has flagged and deleted	0.25
Backoff penalty	A flat deduction if the indexer is currently in Prowlarr's backoff state	−20

The weights, the history window, and the per-hit malicious penalty are all configurable under prowlarr.scoring in Configuration.

Indexers with fewer history records than min_grabs_before_scoring show N/A instead of a score — there isn't enough data to judge them yet.

---

AI-powered scoring (Ollama)

When an Ollama instance is configured under prowlarr.ollama (see Configuration), Inspectarr can hand the full picture of each indexer to a local LLM and let it produce the final health score. The AI receives all of the data the deterministic formula uses, plus additional per-type breakdowns (query failures, grab failures, RSS failures, auth failures) that the formula doesn't weight individually.

The AI scores on a fixed rubric:

Category	Max points	What it evaluates
Reliability	40	Failure rates across all request types
Performance	25	Response time relative to peers
Trust	25	Malicious content history
Availability	10	Backoff state and overall uptime

When AI scoring runs

AI scoring only runs when you click the Rescore button on the Indexers page, or during a scheduled auto-reorder. It never runs on page load or on Refresh — those only show the most recently cached scores.

Fallback behaviour

If Ollama is unreachable, the model errors, or the response can't be parsed, the deterministic score is kept. AI failure never crashes the scoring pipeline or blocks a reorder.

Score caching

Both deterministic and AI scores are cached in the SQLite database. The Reorder & Sync action reads cached scores directly — it never rescores. This keeps reorder fast regardless of whether AI is enabled.

---

Auto-reorder

On the reorder_interval_hours schedule (and whenever you click Reorder & Sync), Inspectarr sorts your torrent indexers by health score and writes new priority numbers to Prowlarr. The best-scoring indexer gets base_priority; the rest count up from there.

Set base_priority above your NZB indexers' priority numbers so the NZB indexers always stay on top — Inspectarr only manages the torrent indexers and won't move them above that line.

Note: Priority writes to Prowlarr use forceSave=true. Without it, Prowlarr runs a live connectivity test on every priority change and rejects the write for any unreachable indexer — which are exactly the ones most in need of demotion. Inspectarr sets this automatically.

Reorder & Sync

The Indexers page has a Reorder & Sync button. It does two things: reorders the indexers by score, then issues Prowlarr's ApplicationIndexerSync command so the new order is pushed out to every connected app (Sonarr, Radarr, Lidarr, etc.).

---

Grab attribution

This is how an indexer earns a "malicious hit." When Inspectarr deletes a bad torrent, it needs to know which indexer served it. That information isn't in Prowlarr's own history (which only records RSS events) — it lives in the *arr's grab history.

So Inspectarr queries the relevant *arr for the torrent's hash, reads the indexer field from the grabbed event, and matches it back to the Prowlarr indexer. That indexer's malicious-hit counter goes up, which lowers its malicious score, which pushes it down the next reorder.

The "(Prowlarr)" naming quirk

When Prowlarr syncs an indexer to a connected app, the app appends (Prowlarr) to the indexer's name. So Radarr's history shows TorrentProject2 (Prowlarr) while Prowlarr's own indexer list calls it TorrentProject2. Inspectarr normalizes this suffix away before matching — you don't need to do anything, but it's worth knowing if you're reading raw history yourself.

Attribution requires an *arr grab

Attribution only works for torrents the *arr grabbed through its normal search flow, because that's what creates the history entry. A torrent you add to qBittorrent by hand, or grab directly from Prowlarr's own search UI, bypasses the *arr and has no history record — Inspectarr can still detect and delete it, but it can't attribute it to an indexer. This is a limitation of where the data lives, not a bug.

---

Stats

The Web UI Stats page rolls this up per indexer:

Column	Meaning
Total Grabs	How many distinct torrents this indexer has served (counted once per torrent, on first sight)
Malicious	How many of those were flagged and deleted
% Malicious	Malicious divided by total grabs

Stats accumulate going forward from when attribution first runs — torrents already sitting in qBittorrent before then aren't counted until they're seen on a scan.

---

Prowlarr API endpoints used

For reference, scoring and attribution rely on these Prowlarr endpoints:

Endpoint	Use
GET /api/v1/indexer	Full indexer list with priorities
PUT /api/v1/indexer/{id}	Writes a new priority (with forceSave=true)
GET /api/v1/indexerstats	Per-indexer average response time and query/failure counts — the source for scoring
GET /api/v1/indexerstatus	Backoff state for failing indexers
POST /api/v1/command (ApplicationIndexerSync)	Pushes indexer order to connected apps

Note: The indexerId filter on Prowlarr's /history endpoint is silently ignored, which is why per-indexer scoring data comes from /indexerstats instead.