Troubleshoot Request: Plex access crashes every morning around 9AM +- 2 hours

Plex Media Server
1

Server Version#: 1.43.0.10389
Player Version#: N/A, All players

Running Plex within a docker on Unraid v7.2.3. Plex has been running stable for months. About 2 months ago plex started crashing (docker reports up) every morning around 9AM give or take 2 hours. Access to the PMS is lost, cannot connect locally or remotely. I know when it crashes at specific timestamps because Tautulli has been reporting it in my discord server. Every morning I restart the docker container to bring PMS back up. I tried looking through the logs searching for error but nothing jumped out at me. I did discover that the container did not have access to the transcode directory and fixed that yesterday (error no longer showing up in the log). That did not fix the issue though because it crashed again this morning. I am beyond my capabilities now, I am debating just doing a fresh install of the container, but really do not want to do that. Hopefully someone can help. Logs attached.

Helpful Timestamps of Tautulli reported down states

Plex Media Server Logs_2026-01-03_11-17-53.zip (3.9 MB)

below:

1/3/26 7:09AM

1/2/26: 9:33AM

1/1/26: 7:45AM

12/31/25: 8:23AM

Best,

Tim

2

The logs provided only cover 1/3/26 7:09AM. To me it looks like the server is doing scheduled tasks. I Know on a few of my servers Plex can get busy with a scheduled task and not respond to Tautulli for a few minutes. Tautulli then reports the server down/up without the server actually crashing. You may want to look at when the scheduled tasks are set to run and move them to a time window where the server is normally inactive.

3

PMS started running scheduled tasks at 02:00 (they appear as Butler tasks in the log files).

Jan 03, 2026 02:00:22.441 [23328333810488] DEBUG - Butler: we're in the window, starting.
Jan 03, 2026 02:00:22.441 [23328333810488] DEBUG - Butler: Waking up!
Jan 03, 2026 02:00:22.441 [23328333810488] DEBUG - Butler: Scheduling randomized task 'RefreshEpgGuides' in 161 minutes.
Jan 03, 2026 02:00:22.441 [23328333810488] DEBUG - Butler: Scheduling randomized task 'RefreshPeriodicMetadata' in 132 minutes.
Jan 03, 2026 02:00:22.441 [23328333810488] DEBUG - Butler: Scheduling randomized task 'ButlerTaskGenerateCreditsMarkers' in 125 minutes.
Jan 03, 2026 02:00:22.442 [23328429288248] DEBUG - Activity: registered new activity 02150da2-4691-4536-8d27-763e2b56444b - "Butler tasks"

They were still running when the Plex server was manually shutdown at 10:51:07: 
Jan 03, 2026 10:50:41.974 [23328429288248] DEBUG - Activity: updated activity 02150da2-4691-4536-8d27-763e2b56444b - completed 100.0% - Butler tasks
Jan 03, 2026 10:51:07.236 [23328542661432] DEBUG - Shutting down with signal 15 (Terminated)
Jan 03, 2026 10:51:07.236 [23328542661432] DEBUG - Ordered to stop server.
Jan 03, 2026 10:51:07.279 [23328542661432] DEBUG - [JobRunner] Job running: /usr/lib/plexmediaserver/CrashUploader --sessionStatus=exited --sessionStart=1767381020 --sessionDuration=85247 --version=1.43.0.10389-8be686aa6 --userId=northfootball73@gmail.com --sentryUrl=https://o17675.ingest.sentry.io/api/1233455/ --sentryKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jan 03, 2026 10:51:07.290 [23328542661432] DEBUG - [JobRunner] Jobs: Starting child process with pid 20635
Jan 03, 2026 10:51:07.290 [23328651299472] DEBUG - Stopping server...
Jan 03, 2026 10:51:07.290 [23328651299472] DEBUG - HttpServer: Stopping server.

As @dbirch mentions, if the system is busy with scheduled tasks, such as optimizing the database, it may become non-responsive and give the appearance of a crash when one did not actually occur.

It can also happen if other applications such as Kometa are accessing the Plex database.


I also noticed these messages in the log files (Plex Media Server.log).

Check permissions for the transcode directory.

Jan 02, 2026 12:18:26.360 [23328346467128] DEBUG - IntroDetector: Initializing for "/media/tv/Mickey Mouse Clubhouse (2006) {imdb-tt0784896}/Season 01/Mickey Mouse Clubhouse (2006) - S01E02 - A Surprise for Minnie [DSNP][WEBDL-1080p][AAC 2.0][h264]-LAZY.mkv" (42369)
Jan 02, 2026 12:18:26.360 [23328346467128] ERROR - IsFileWritable: failed to create file '"/transcode/3def4a50-f115-4bd1-9b3d-7f6ae88ba289"'
Jan 02, 2026 12:18:26.360 [23328346467128] WARN - IsDirWritable: directory '"/transcode"' is not writable
Jan 02, 2026 12:18:26.361 [23328346467128] ERROR - Error creating directory "/transcode/Transcode/Detection": Permission denied
4

Thanks for the response. I can confirm that the server is inaccessible when Tautulli reports it down. I will have to restart the docker container in order to bring plex back up. I did notice that the scheduled times to do tasks was 0200-0500. I moved it to 0000-0600. Do you think that the 3 hours was not long enough to get all the tasks done, and then possibly was getting hung up?

Is there a way for me to get logs prior to 1/3/26 709AM? I went to troubleshoot tab and download logs to get the current set of logs.

Appreciate it.

5

Unfortunately plex rolls the logs regularly and only keeps information for a period of time. In your case the logs cover about 24 hours (In the general Plex Media Server.log series of logs. Specially logs do go back further but rarely contain relevant information.

6

Thanks for the response. Tasks were previously set for 0200-0500. I extended that after I gave logs to 0000-0500. Is there a recommended time/duration for scheduled tasks? Especially for larger libraries? Should I even set a cutoff at 0500? Maybe I should just let it run indefinitely until 0000 (24 hours).

I can try shutting down kometa as a test to see if kometa is possibly crashing plex.

As for the transcode directory, good catch. I found those prior to the post on 1/2, and I believe I fixed that. I will go back and check tomorrow to see if there are any more permission issues in the logs from 1/3 and after.

Thank you.

7

Good to know, if the issue persists, Ill post updated logs tomorrow, immediately after the crash. Thanks again

8

One thing to try, is using ChuckPa’s database repair script GitHub - ChuckPa/DBRepair: Database repair utility for Plex Media Server databases not to fix the database, but especially with large databases they can start to have performance issues long term. Any time I do significant amounts of media changes Ill run it as a matter of housekeeping. After it does an automatic process I always see a significant boost in performance.

9

Ill give it shot, thanks for the tip.

10

Additional thoughts…

  1. Run PMS v1.42.2, the public release, unless you have a specific need for the beta release. 1.43.0 has a new transcoder and Plex is still working out the bugs. PMS uses the transcoder for many of the scheduled tasks.

  2. Run DBRepair for Plex Media Server.

Since PMS is shutdown when DBRepair runs, it can perform a more thorough database optimization than the regular scheduled task. This will make the system more responsive.

Use the AUTO option. It will check the db for structural problems, attempt to repair any it finds, then optimize the database.

The README file has instructions on running it when using Docker.

11

Appreciate the feedback. Will get to work doing 1 and 2. Thanks again

12

Definitely shutdown Kometa, at least for testing. There have been other posts of it basically hogging the Plex db. Plex does not really crash. It just becomes non-responsive to users since it is so busy with Kometa.

Hard to say because every server is different.

Whatever tasks are running will run to completion even if the window closes. Any tasks that did not run will be rescheduled for the next maintenance window.

As @dbirch mentions, move the window to a time when there are few people using the server and leave it open as long as possible.

If there is a day when you know there won’t be too much streaming, open the window for a very long period - maybe 12 hours. That will give Plex time to catch up on things. You can shorten the window later (also turn off Kometa during that large window so it does not interfere with the tasks).

13

OK. So update on today. I ran the DB repair script on auto yesterday. It completed successfully. I did not shutdown kometa, and I did not switch to PMS v1.42.2 yet.

Plex crashed at 9:48AM this morning, and came back up at 12:40PM on its own (according to Tautulli notifications).

I have shut down kometa just now, and will see if Plex crashes again tomorrow morning. If this does not work, then will switch the version. Just easier to do this incrementally with my limited time during the week.

Logs if you are interested in taking a look. I found the following error at 9:46 in Plex Media Server.2.log file, but unsure what to do about it.
Jan 05, 2026 09:46:15.365 [23015996873528] ERROR - [Req#3722b] Unknown metadata type: folder

Plex Media Server Logs_2026-01-05_17-46-23.zip (4.5 MB)

Thanks,

Tim

14

Typically when plex crashes it goes down and requires a manual restart unless you have some kind of watch dog script that restarts it.

What this sounds like is the database is getting busy and ignoring Tautulli. I will say apps like kometa can absolutely hammer plex’s database, leading to the notices you are getting.

15

Ignore it. It is a false alarm.

That error has been around for quite some time.

The Plex devs changed something in the code, but didn’t update log messaging.

16

Mine also crashed two days in a row now. Kometa was running when it happened so I blame Kometa..

17

Thanks for all responses. It was kometa. Since stopping the kometa container, plex has been up for 3+ days now.