Since I pulled a new image (hotio:nightly) yesterday, the Seerr interface has been very slow and auto approve requests are failing regularly. Please note I've been running hotio:nightly since it became the new merged Seerr beta. I haven't had any issues like this until now. Log attached. You'll find most of what I saw towards the end of this log.
#Slow Interface and Requests timing out
116 messages · Page 1 of 1 (latest)
only thing alarming i see is timeouts to your arr exceeding the 5000ms and causing a error. are the arr's reachable?
Yes. Everytime I go in and do a test they pass.
has anyone else on hotio reported issues?
run this and see what the time is to reach radarr docker exec seerr curl -w "\nTime: %{time_total}s\n" http://radarr:7878/api/v3/system/status?apikey=YOUR_API_KEY
None that I've seen.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{
"appName": "Radarr",
"instanceName": "radarr",
"version": "6.0.4.10291",
"buildTime": "2025-11-14T23:25:20Z",
"isDebug": false,
"isProduction": true,
"isAdmin": false,
"isUserInteractive": true,
"startupPath": "/app/bin",
"appData": "/config",
"osName": "alpine",
"osVersion": "3.22.3",
"isNetCore": true,
"isLinux": true,
"isOsx": false,
"isWindows": false,
"isDocker": true,
"mode": "console",
"branch": "master",
"databaseType": "sqLite",
"databaseVersion": "3.50.4",
"authentication": "external",
"migrationVersion": 242,
"urlBase": "",
"runtimeVersion": "8.0.12",
"runtimeName": "netcore",
"startTime": "2026-02-10T06:08:04Z",
"packageVersion": "release-1a57dc4",
"packageAuthor": "[hotio](https://github.com/hotio)",
"packageUpdateMechanism": "docker"
100 821 0 821 0 0 250k 0 --:--:-- --:--:-- --:--:-- 267k
}
Time: 0.003200s
response time is fine so something else is deff going on
only thing I can think of is maybe this is happening when the network is being stressed from lots of requests and subsequent downloads happening at the same time.
Also to note, Seerr and Radarr/Sonarr are in different networks. Seerr in custom bridge network and Sonarr/Radarr in macvlan. Though as I'm talking about it, maybe worth me putting Seerr in the same macvlan network.
your response is 3.2 milliseconds way under the threshold
i'll have to run this test tonight when my server is in "prime" time
its generally recommended to keep all your apps on a custom docker network tho your approach should work as well.
We recently added a timeout
To service api calls if it exceeds too much
It will timeout
For some reason the radarr/sonarr calls are taking too long
That shouldnt happen
Can you press test on services
And send logs too
So we can see whats wrong w your network
ahh i missed that one. ill let fallen take it from here 🙂
Im also seeing this
info][Plex Scan]: Recently Added Scan Complete
2026-02-10T03:10:07.561Z [debug][API]: Something went wrong retrieving movie {"errorMessage":"[TMDB] Failed to fetch movie details: Request failed with status code 404","movieId":"1483978"}
404 on tmdb
So there's a combination of network issues happening including dns

Can i see your compose?
Please note I've been running hotio:nightly since it became the new merged Seerr beta
It's not, seerr have this own image why use hotio image ?
seerr:
container_name: seerr
image: ghcr.io/hotio/seerr:nightly
networks:
- swag
ports:
- 5055:5055
volumes:
- ${APPDATA}/seerr:/config
environment:
- fpm=false
- branch=dev
- TP_HOTIO=true
- TP_THEME=dark
extends:
file: .docker-compose.extends.yaml
service: common
you use nightly we can't know which version you are running on
if you could get us the commit you are running on would be nice
But I was migrating from Overseerr and was told I had to run hotio:nightly to migrate and not lose anything
e3dc1c302d18bc9618dcd2eb0f99c1c59b438df2
Overseerr migration is handled by seerr script
Ok well about a month ago i saw people saying to just switch from ghcr.io/hotio/overseerr:latest to ghcr.io/hotio/seerr:nightly and everything would just work
and it has
until yesterday
but it looks like maybe I have had these underlying issues and didn't know about it
Can yiu share your arr compose
I don't think it comes from your third party image, just saying I don't understand why people use this
radarr:
image: ghcr.io/hotio/radarr:release
container_name: radarr
networks:
vlan140:
ipv4_address: 10.4.140.213
ports:
- 7878:7878
volumes:
- ${APPDATA}/radarr:/config
- /mnt/fast_storage:/fast_storage
- /mnt/storage:/storage
- /optane/scripts/theme.park/98-themepark-radarr:/etc/cont-init.d/98-themepark
environment:
- TP_HOTIO=true
- TP_THEME=dark
extends:
file: .docker-compose.extends.yaml
service: common
Yup it could be why. Previously requests will go on forever withoit timing out so youll never realise when requests take way longer than it should
still want that test log?
can you do docker compose pull on seerr ?
As in api calls to arr
Ok running 028c7c24344294f38f8fb029971735208de4fac6 now
ahah
nightly sucks 🙂
you don't have the last commit
I guess it rebuild every X hours
it's why develop is better it rebuilds on new commit
Better?
it's the latest version at least (if you want that)
@tranquil lotus could you add the dns block
dns:
- 9.9.9.9
- 8.8.8.8
- 1.1.1.1
Into your compsoe
And then check if browsing around is slow
Also press test in services and send logs
Will do
First time browsing to movies and series tabs was slow to load posters but now subsequent scrolling down to load more posters is snappy. Tests are passing. But will clear log, test again and post log here shortly.
Hmmm, deleting the seerr.log and rebooting doesn't generate a new log file?
a) It should not be deleted when seerr is running
b) now to fix that you might need to stop and delete entire logs folder too (or back it up)
Still there is dns issues then. Subsequent uses cached
Try enabling settings > networks > force ipv4 option
And restart
When I do service tests I'm not seeing those in the logs
FYI I don't have DNS Cache enabled in case I should
Thats for last resort
Thats mostly if you wanna avoid dns spam
off topic, but is there a quick way to disable watch list for all users? When I select all users and do bulk edit it's greyed out
[error][Plex.TV Metadata API]: Failed to retrieve watchlist items {"errorMessage":"Request failed with status code 401"}
That specific user need to log out and back in to refresh their plex token
got it. I kind of want to just disable watch list for all users
Interface is still super slow and requests showing as failed with timeout of 5000ms exceeded even though they are in fact being added to radarr.
what tag version did you add the timeout? Im curious if I downgrade back to before that change if things "work" again
just so I can isolate that it is indeed the change the brought this issue to light
It’s not the version as there’s been no other reports, and for myself it’s still been fine. I suspect a network issue going on.
possible. Just strange that none of my other 50+ containers seem to be having an issue. I think I'll just let this go for now though because I have like 50 new server parts in my office ready to rebuild my whole server stack at home which will include many underlying changes so we'll see where the dust settles when that's all done 😄
Its possible that the networking issue is going unnoticed. The timeout is what made it show
Could be. We can close this for now since like I said I'm making massive changes to my server and network infrastructure in the coming weeks so I'll revist this when all the dust settles. I appreciate your time in helping to troubleshoot.
Yes ofc. Just ping me, and I'll try and help out 😄
Sorry, to ping an old post but I am experiancing something very silimer, Radarr and Sonarr keep timing out but the log show no info other than "request timed out"
Please send the full logs
nope using seerr/seerr
2026-02-14T19:51:39.528Z [error][Radarr]: [Radarr] Failed to retrieve root folders: timeout of 5000ms exceeded
2026-02-14T19:51:40.580Z [error][Radarr]: [Radarr] Failed to retrieve root folders: timeout of 5000ms exceeded
Are you connecting to it via local ip
Could just be thay container cant reach them
So currently we timeout after 5seconds of trying to reach
So please show us your compose + explain your setup
So we can go through the troubleshooting steps together
Sure, I have made a post here https://discord.com/channels/783137440809746482/1472319803145326643
Thanks 🙏
Can you try preview-servarr-timeout-increase-more
Will do later today and report back. 👍
Looks like moving from image: ghcr.io/hotio/seerr:nightly to image: ghcr.io/seerr-team/seerr:preview-servarr-timeout-increase-more is a no go. Essentialy takes me to the setup wizard.
Thata bwvause your mount is different
Between hotio and our image
Please send compose
seerr:
container_name: seerr
# image: ghcr.io/seerr-team/seerr:preview-servarr-timeout-increase-more
image: ghcr.io/hotio/seerr:latest
networks:
vlan140:
ipv4_address: 10.4.140.214
ports:
- 5055:5055
volumes:
- ${APPDATA}/seerr:/config
environment:
- fpm=false
- branch=dev
- TP_HOTIO=true
- TP_THEME=dark
extends:
file: .docker-compose.extends.yaml
service: common
Yeah your internal path should now be /app/config
ok i'll change it for this test.
First test request since the updated image run went through successfully. Interface is still a bit laggy but at least the requeset didn't fail
Add in
dns:
- 9.9.9.9
- 8.8.8.8
- 1.1.1.1
Should make it a bit betrer
I took that out because last time we tested it didn't seem to make much difference but I'll add it back in and try again
That was because it was a whole different issue right? We were trunna deal with the exceeded ms one
Correct, and yes adding that back in makes the interface much snappier
You can stick to that preview image for now. We plan to add the timeout as a configurable field for next version
Will do. Thanks so much for troubleshooting this with me