Troubleshooting

This page covers the most common problems and how to resolve them. If your issue isn't listed here, check the logs first — they almost always point to the cause.

Finding the Logs

Seekarr writes logs to /config/logs/ inside the container, which maps to your host volume path. You can also view live logs directly from the Seekarr UI under the Logs tab, or from the terminal:

docker logs seekarr
docker logs seekarr --tail 100 -f   # follow live output

Enabling DEBUG mode

The default log level is INFO. DEBUG mode adds verbose output including per-item decisions, API request details, and state checks — useful when you can't tell why Seekarr is or isn't doing something.

Option 1 — UI: Settings → General → enable Debug Mode. Takes effect immediately without a restart.

Option 2 — environment variable: set DEBUG=true in your docker-compose.yml and restart the container. This also enables Flask's development server.

environment:
  - DEBUG=true

Turn DEBUG off again once you're done — it produces a large volume of output during normal operation.

Connection Test Failures

The connection test button in each app's settings sends a request directly from the Seekarr container to the *Arr host and port you entered. A failure means Seekarr cannot reach the app — it does not indicate a problem with Seekarr itself.

Checklist

1. URL and port — confirm the URL is reachable from inside the container. If Seekarr and your *Arr app are on the same Docker network, use the service name (http://sonarr:8989), not localhost. localhost inside the Seekarr container refers to the Seekarr container itself.
2. API key — copy it directly from the *Arr app (Settings → General → Security) and paste it fresh. A single extra space will cause a 401 Unauthorized error.
3. Network reachability — run a quick connectivity check from inside the container:

   docker exec seekarr python3 -c "import urllib.request; print(urllib.request.urlopen('http://sonarr:8989/ping').read())"

4. SSL errors — if the URL is HTTPS with a self-signed certificate, see the SSL Errors section below.
5. Firewall / network policy — confirm no firewall or VLAN policy is blocking the connection between containers.

Error: "Connection refused"

The *Arr app is not listening on that port, or the port is wrong. Check that the app is running and confirm the port in its settings.

Error: "Name or service not known"

The hostname cannot be resolved. If using Docker service names, make sure both containers are on the same Docker network.

Error: 401 Unauthorized

The API key is wrong. Re-copy it from the *Arr app's settings page.

SSL Errors

If your *Arr app uses a self-signed certificate you will see an error like:

SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate

You have three options — see the Self-Signed Certificates section of the Configuration guide for full details on each:

• Custom CA bundle (recommended) — Settings → General → Custom CA Bundle Path. Point it at your CA cert inside /config.
• Disable SSL verify — Settings → General → turn off Enable SSL Verify. Simple, but skips all certificate validation.
• Mount cert into container trust store — bind-mount your CA cert into /usr/local/share/ca-certificates/ and run update-ca-certificates at container start.

No Items Found / Nothing Being Searched

Seekarr reports finding zero items to search. The most common causes:

Monitored Only is enabled

When Monitored Only is on (the default), Seekarr skips anything not marked as monitored in your *Arr app. If your library items are all unmonitored, Seekarr has nothing to process. Check the monitored status in Sonarr/Radarr and re-monitor the items you want searched.

State tracking — all items already processed

Seekarr records which items it has already processed and skips them on subsequent cycles. If every eligible item has been processed at least once, Seekarr will idle until the state reset interval expires (default 7 days). You can reset state manually from Settings → Stateful Management → Reset State, or wait for the automatic reset.

Hunt limits set to zero

The Missing Search and Upgrade Search values in each app's settings control how many items are processed per cycle. If either is set to 0, that type of search is disabled.

App not enabled or not configured

An app must have a valid URL, API key, and at least one instance saved before Seekarr will start its background loop. Check that the connection test passes and that the app is enabled.

Whisparr v2 vs Eros (Whisparr v3)

Seekarr supports two generations of Whisparr, which use different API versions:

If connection tests or searches fail for Whisparr, confirm which version you're running. Check the Whisparr web UI — v3 shows "Eros" in the title or version string. Use the Eros app in Seekarr for v3, and the Whisparr app for v2.

Connecting v3 to the Whisparr app (or vice versa) will result in API errors or empty results.

Locked Out After Failed Login Attempts

Seekarr locks an IP address out of the login page for 15 minutes after 10 consecutive failed attempts. If you're locked out:

• Wait 15 minutes — the lockout expires automatically.
• Restart the container — lockout state is in-memory and clears on restart:

  docker restart seekarr

If you've forgotten your password, the only recovery path is to delete /config/user/credentials.json and restart the container. Seekarr will redirect to the setup page to create a new account.

docker exec seekarr rm /config/user/credentials.json
docker restart seekarr

Still Stuck?

If none of the above resolves your issue:

1. Enable DEBUG mode and reproduce the problem — the debug output usually identifies the exact cause.
2. Search the GitHub issues to see if it's a known problem.
3. Open a new issue with your Seekarr version, the relevant log lines, and a description of what you expected vs. what happened.