26 Mar 2026 · infrastructure · 6 min read

Your Watchlist Is Dead Weight Without a Policy Layer

I had the same bad week a lot of media-automation people eventually have. Trakt looked full, Sonarr looked busy, and my library got worse.

I had the same bad week a lot of media-automation people eventually have. Trakt looked full, Sonarr looked busy, and my library got worse.

Three shows I had half-watched turned into a wall of downloads I did not want. A documentary my partner added as a joke got queued because it matched the rules. A cancelled series with six episodes kept getting rechecked because the sync tool never asked whether it still made sense to add it. Nothing was technically broken. That was the problem. Every system in the chain was doing exactly what it had been told to do.

Trakt had recorded intent. Sonarr had accepted the request. The missing piece was judgment.

The mistake is treating a watchlist like a queue. A watchlist is just a list of interest. It says, “maybe later.” It does not mean “download now.” Once you connect Trakt directly to Sonarr or Radarr, you have already skipped the only step that matters: deciding whether the thing should be added at all.

That is why a policy layer helps. It sits between the thing that remembers what you might want and the tool that starts watching for it. It can say yes, no, or not yet. Without that layer, everything in the watchlist qualifies by default. That sounds automated until you are the one cleaning up the mess.

The Failure Mode

The first version of this setup was the simplest possible one. Trakt sync fed straight into the arr apps. If something appeared on the list, it was added. That is the kind of automation that feels elegant until the second or third sync.

The failure is not subtle. You open your dashboard and see a pile of items that were never meant to be downloaded. A show you added while browsing becomes a permanent task. A one-off movie gets grouped into a full library automation path. Something that was supposed to be a note turns into an order.

This gets worse because the tools are behaving correctly from their own point of view. Trakt is not wrong for storing the item. Sonarr is not wrong for accepting the request. Radarr is not wrong for starting a search. The failure is in the assumption that those tools should decide what enters the pipeline.

That is the part people often try to solve with more settings inside Sonarr or Radarr. It helps a little, but it does not solve the original problem. Those apps are excellent at executing a decision. They are not where the decision should be made.

What The Policy Layer Does

The policy layer is not fancy. It is just the place where rules live before anything hits Sonarr or Radarr.

The rules I found useful are boring in the best way:

• Skip things already in the library.
• Skip shows that are obviously too thin to be worth tracking.
• Skip ended shows that were added impulsively and never fit the rest of the stack.
• Allow manual overrides when I actually want to force something through.

That sounds obvious until you try to express it only inside the arr tools themselves. They can score and filter downloads, but they are still downstream. By the time a show has reached Sonarr, the decision to add it has already happened.

What the policy layer gives you is a place to say “not this one” before the apps start behaving like the choice was final.

The shape is simple:

Trakt watchlist
  ->
policy checks
  ->
Sonarr or Radarr only if it passes

In practice, that means a sync job can inspect the item first. If a show is already in my library, it stops there. If a movie is tagged as “do not auto-add,” it stops there. If a series looks like one of those things you add while tired and forget by morning, it stops there too.

When the item does pass, the sync layer forwards it normally. Sonarr and Radarr still do the part they are good at. They just do it after the wrong calls have been filtered out.

How I Would Build It

The implementation does not need to be dramatic. It needs to be readable.

I would keep the policy in one small service or script with three inputs:

1. The incoming Trakt item.
2. The current library state.
3. A compact rule file with human edits.

That rule file should be obvious enough that future-you can open it and know why something got through. It might look something like this:

[eligibility]
min_episode_count = 6
allowed_statuses = ["continuing", "ended"]
skip_if_already_in_library = true

[overrides]
bypass_tag = "manual-override"
always_skip_tag = "not-interested"

[routing]
max_retries = 2
timeout_seconds = 10

The exact numbers matter less than the fact that they are visible. If I want to change the behavior later, I want one place to do it. I do not want to rediscover a rule buried in a Sonarr profile, a Trakt tag, and a cron script all at once.

The sync itself should be plain and readable too:

for item in watchlist:
    if already_in_library(item):
        continue
    if not eligible(item):
        continue
    add_to_sonarr_or_radarr(item)

That is the point. The hard part is not the for-loop. The hard part is admitting that this is a decision-making problem, not just an API integration problem.

The Rule Set

Once the policy layer exists, the rules stop being hidden habits and start being explicit.

For me, the useful rules were:

• Do not auto-add shows I only sampled.
• Do not auto-add anything already present in Plex or the arr library.
• Do not let one enthusiastic watchlist sync pull in a pile of garbage.
• Let manual overrides exist, but make them deliberate.

That last one matters. There is always a case that should break the rule. A pilot you want to keep. A weird documentary series you know you will actually watch. A show with four episodes that is worth tracking anyway. The rule should allow exceptions, but the exception should be visible.

The policy layer is useful because it makes those exceptions a choice instead of an accident.

It also gives you a better mental model for maintenance. If a rule blocks something you wanted, you know where to look. If a sync starts pulling in junk again, you know the issue is in the policy, not in six separate downstream tools. That makes the system easier to trust, which is the real goal.

Why It Feels Better

The biggest improvement was not fewer downloads. It was less doubt.

Before the policy layer, every sync felt like handing my watchlist to a machine and hoping it understood the difference between interest and intent. Afterward, I could look at the rules and see why each item was accepted or rejected. The pipeline stopped feeling like a black box.

That is why this pattern holds up. It does not make Trakt smarter. It does not make Sonarr or Radarr smarter. It just puts the judgment where it belongs, before the tools that act on it.

If your automation keeps downloading things you never meant to add, the fix is usually not “more automation.” It is one layer of restraint. Let Trakt remember what you are interested in. Let the policy layer decide what is actually worth actioning. Let Sonarr and Radarr do the downloading only after that decision has already been made.

A passive watchlist is a list of good intentions that never propagates. The gap between ‘I want to watch this’ and ’Sona

A passive watchlist is a list of good intentions that never propagates. The gap between ‘I want to watch this’ and ’Sona