Detection and Actions

This page explains exactly what Inspectarr does on each scan: how it decides a torrent is bad, how badly, and the sequence of actions that follows.

---

The scan cycle

On each cycle (every poll_interval_seconds, or when you click Run Now), Inspectarr:

1. Loads config.yaml fresh from disk.
2. Resolves any quarantine holds whose timeout has elapsed.
3. For each rule, fetches the torrents in that rule's category.
4. For each torrent not already handled, pulls its file list and evaluates the rule's conditions.
5. If a torrent is flagged, grades the findings and runs the outcome below.
6. Writes a scan_complete summary: torrents checked, flagged, and actioned.

Torrents are skipped if they were already actioned in a previous scan, are sitting in the retry queue, or are currently held in quarantine — in each case something else already owns them.

---

From match to outcome

A rule match does not go straight to deletion. Each condition that fires produces a finding, each finding is graded, and the worst grade decides what happens.

findings  ->  severity per finding  ->  worst one wins  ->  band  ->  outcome

Band	Outcome
Below min_severity	Recorded only. Nothing is paused, blocklisted, or deleted.
Between the thresholds	Quarantined — paused and held for review.
At or above remediate_at	Remediated — the sequence below.

Both thresholds default to LOW, so out of the box every flagged torrent is remediated immediately. See Quarantine & Severity for how to open a review band.

---

The remediation sequence

When a torrent lands in the remediate band and Dry Run is off:

1. Grab attribution (Prowlarr only). Inspectarr looks up which indexer served this torrent by querying the relevant *arr's grab history. This must happen first, because the next step adds a new history event that would otherwise hide the original grab. See Prowlarr Indexer Scoring.
2. Blocklist in the *arr. The release is marked as failed in Sonarr, Radarr, or Lidarr. This blocklists it so the *arr never grabs the same release again, and triggers a re-search for a good copy.
3. Delete from the torrent client. The torrent and its files are removed.
4. Record the result. The hash is stored as processed, an inspection record is written with the full evidence, the indexer's malicious-hit counter is incremented, and an ACTION event goes to the log.
5. Notify. A notification fires if action is in your notify_on list. See Notifications.

---

The evidence trail

Every flagged release — including catches below min_severity that are never acted on — writes an inspection record: what was seen, how it was graded, what was decided, and what actually happened. Each finding is stored separately with its own severity, file, and the specific extension or pattern that matched.

Every event belonging to one catch shares an inspection_id, and every scan shares a scan_id. Grepping a single ID follows one torrent from detection through the *arr call, the client operation, any retry, and the final outcome — rather than correlating timestamps by hand.

---

When an *arr call fails

If the blocklist call fails (the *arr is down, a network blip), the on_arr_failure setting decides what happens:

• delete (default) — the torrent is removed from the client anyway, and the failure is logged and notified. The bad payload is gone, but the *arr may grab it again since it wasn't blocklisted.
• abort — nothing is deleted. The torrent is queued for retry, up to retry.max_attempts times, retry.interval_seconds apart.

Choose abort if you'd rather keep a bad torrent temporarily than risk it being re-grabbed; choose delete if you want the bad payload gone immediately no matter what.

If the client delete fails after a successful blocklist, that is recorded as a client_delete_failed event and the torrent is queued for retry.

---

Dry Run

With dry_run: true, detection and grading run exactly as normal but nothing is paused, blocklisted, or deleted. Matches are written as dry_run events showing the risk level and the decision that would have been taken. This is the safe way to validate rules and thresholds — see Rules.

---

What Inspectarr does not do

• It does not delete torrents just because a video was removed from an *arr or a release was upgraded — it only acts on rule matches.
• It does not touch torrents in categories no rule watches.
• It does not use AI to decide anything about a torrent. Severity is deterministic; Ollama is only ever involved in indexer scoring and notification summaries.
• It cannot attribute or act on the indexer for torrents added manually to the client or grabbed directly in Prowlarr's UI — those have no *arr history entry. See the FAQ.

---

Before any of this applies

Everything on this page describes what happens in Automatic mode, which is the default. A single setting caps how far Inspectarr may act, regardless of what your rules and thresholds say:

remediation:
  operating_mode: automatic   # monitor | quarantine | automatic

• Monitor — findings are graded and recorded; nothing is paused or deleted.
• Quarantine — nothing is deleted automatically; matches are held for review.
• Automatic — the thresholds are applied as written.

It only ever reduces an outcome, and it never rewrites your thresholds. See Modes, Quarantine & Severity.