Build a short event sequence
Ask the authorised server operator to compare the upgrade start, server startup messages, health-check results and restart events. Record the component initiating each restart where that information is available. A container supervisor stopping a process is a different observation from the process reporting its own fatal error.
For an illustrative diagnosis, a migration begins, the monitoring check fails, and the supervisor immediately restarts the service. Repetition of that sequence suggests the monitoring policy needs review. It does not prove the database is corrupt or establish that allowing an arbitrary amount of time will solve every startup problem.
Keep the health endpoint within its scope
The official monitoring guide says /health checks underlying HTTP and database connectivity, with 200 OK for success. It also states that this endpoint does not function as expected while startup is underway. A normal steady-state check should therefore not be read as an unconditional startup deadline.
Even a successful health response is narrower than a complete viewing test. It does not establish that a particular account, media mount, subtitle renderer or remote client has passed. Preserve that distinction when reporting recovery so a green service indicator does not erase a separate playback fault.
Review the supervisor with the operator
Have the operator compare the deployment’s documented startup grace period, failure thresholds and restart policy with the migration evidence. No universal timeout is supplied here: database size, storage and the actual operation can differ. Keep the previous configuration and a recovery plan before changing operational settings.
Avoid repeatedly interrupting the same migration or replacing database files from unrelated versions on the strength of one red indicator. If the logs instead identify a concrete application error, investigate that evidence. The order of events determines whether the next step concerns a monitoring policy or a server failure.
Validate service and viewing separately
After startup completes, confirm the expected steady-state health result, then inspect library availability and one permitted playback path. Record the server release and the monitoring change so the next upgrade can be assessed with the same context. Keep tokens, home addresses and detailed private metrics out of public reports.
This is an operational decision guide based on Jellyfin’s explicit startup warning and an original event-sequence example. It does not run a watchdog, alter a home server or report a successful migration. Its useful outcome is a precise explanation of which component stopped the process and whether that decision respected the startup stage.
Questions about this guide
Does a failed /health response during startup prove a corrupt library?
No. Jellyfin warns that the endpoint does not function as expected during startup.
Does 200 OK prove a film plays successfully?
No. The documented endpoint checks HTTP and database connectivity, which is narrower than a viewing test.