Name the work and its dependency
Jellyfin exposes separate tasks including Scan Library, Extract Chapter Images, Optimize Database and Clear Transcodes Folder. Treat each task as an operation with an input, output and dependency rather than as a generic cleanup switch. A scan needs the expected media to be available; a generated-image job needs time and storage; a cleanup operation needs the administrator to understand what it can remove.
Inventory the tasks enabled on your own server, their triggers and the reason each exists. Add the periods when people normally watch or listen and the time when network storage becomes available after a restart. Use the actual task list in the installed release, including any plugin tasks, rather than assuming another installation's list is identical.
Prevent a startup dependency mistake
The documented Clean up collections and playlists task runs at startup by default; the guide warns that unavailable media can cause playlist loss. That makes startup order part of a maintenance plan. A running Jellyfin process is not sufficient evidence that every media location is ready to be assessed.
For a proposed household server, distinguish operating-system boot, successful media mount and library maintenance. Record how the administrator verifies the mount before running work that relies on it. Do not test the consequence by disconnecting a live library containing valued playlists. Preserve relevant data and use an isolated sample if you need to rehearse an unavailable-storage scenario.
Allocate a window with evidence
Choose a small initial maintenance window based on actual use, then record when the selected task starts and finishes locally. Avoid inventing a universal duration from the size of somebody else's library. A task that completes quickly on one server may overlap evening viewing after more media, subtitles or generated assets have been added.
Separate jobs where doing so makes the outcome easier to understand. If a scan and another heavy task begin together, a playback issue gives little indication of which workload contributed. Review available storage before generated-output jobs and compare the result after one change. The purpose is controlled scheduling, not a claim that maintenance can never affect playback.
Review both completion and side effects
An acceptance record should include the task name, trigger, observed completion, storage state and any user-facing consequence. Check the library result appropriate to that task. A completed scan that missed an unavailable share is not equivalent to a complete inventory; a cleanup that succeeded technically may still have operated under an unwanted assumption.
Keep a simple fallback: pause the questionable schedule, preserve the evidence and restore the last understood arrangement while investigating. Revisit timing after adding a large collection, changing storage or upgrading plugins. The finished plan states which prerequisites must be true and how the result is checked, allowing another administrator to maintain it without guessing why a time was chosen.
Questions answered
Should every task run immediately after boot?
Review its prerequisites first. Tasks that rely on media availability need a plan for delayed or failed mounts.
Does a successful task status prove my library is complete?
No. Also inspect the task's relevant result and whether all expected media paths were available.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.