How to Reduce Immich Startup Time After Reboot

If Immich is slow to become usable only after the home server reboots, measure which dependency becomes ready last before trying to “speed up” the application itself.

A reboot can make storage mounts, PostgreSQL, network paths, DNS, or other services arrive in a different order than they do during a normal Immich restart. The useful metric is not when Docker says a container started; it is the time from host boot until the database is accepting real requests, required storage is mounted, Immich stops retrying dependencies, and a client can load the timeline. Capture that sequence once, then remove the actual wait or retry loop.

Measure the Boot Timeline Before Changing Anything

Reboot during a maintenance window and timestamp four points: host reachable, Immich-related storage mounted, database healthy, and Immich usable from a client. Also capture container start times, health states, restart counts, and the first useful log line from each service. This turns “startup feels slow” into a bounded delay.

Compare the result with a normal stack restart performed after the host is already fully up. If Immich restarts quickly later but is slow only at boot, the bottleneck is probably an ordering or readiness dependency outside the application. If both are equally slow, investigate database work, storage latency, migrations, or CPU pressure instead.

Do not optimize all layers at once. The exit from this stage is the identity of the first component whose readiness lags behind its container start time or repeatedly forces Immich to retry.

Check Whether Storage Is Ready Before Immich Starts

Confirm every bind mount and network-backed path exists and contains the expected data before the Immich services start. A mount point can exist as an empty local directory while the real disk or NAS share is still unavailable, which can make the application start against the wrong filesystem view.

If your database or media resides on storage that appears late during boot, make the service depend on that mount at the host level or delay the stack until the mount is verifiably present. The test should check the actual mounted filesystem or a known marker, not only that the directory name exists.

After adjusting storage readiness, reboot again and compare the same timestamps. A successful change removes retries or empty-path behavior without changing the steady-state Immich configuration. If storage was already ready well before the database, move to the dependency sequence instead of adding arbitrary sleep timers.

Wait for the Database to Be Healthy, Not Merely Running

PostgreSQL can have a running container before it is ready to accept the application’s workload, especially after an unclean stop, storage delay, initialization, or recovery. Compare the database health transition with the first Immich connection errors in the boot logs.

Simple startup order can launch a dependent container before the service it needs is actually ready. Where your Compose version and service definitions support it, health-based dependency checks can distinguish “container started” from “dependency ready.” Use them to remove avoidable reconnect cycles rather than hiding a slow or unhealthy dependency.

Keep the readiness check narrow and meaningful. A database check should prove it can accept the connection Immich needs; it should not run an expensive query that adds its own delay. Once database readiness precedes Immich startup consistently, repeat the host reboot test before changing anything else.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separate Retry Loops From Legitimate Startup Work

If storage and PostgreSQL are ready but Immich still takes much longer after reboot, inspect the application and worker logs for repeated connection failures, failed health checks, migrations, job initialization, or resource pressure. Repeated errors with fixed intervals often indicate waiting; sustained CPU or disk work with forward progress indicates real startup work.

Dependency order works best when paired with meaningful health checks instead of short fixed delays. A Compose health-check pattern can help prevent an application from racing a database or cache that is still initializing. Keep the checks realistic; shortening intervals until a sick service looks healthy does not improve startup.

If restart counts climb during boot, pause the storm and identify the first unavailable dependency before tuning CPU, memory, or image startup parameters. A container restart-loop dependency check helps separate a slow prerequisite from a problem inside Immich itself.

Reboot Again and Verify Time to Real Usability

After one targeted change, perform a full host reboot and record the same timestamps. A genuine improvement should shorten the gap between dependency readiness and a usable Immich client without introducing new restart loops, missing mounts, or background errors.

Test more than the web login page. Open several old photos, run a search, load a representative video, confirm a mobile client connects, and upload one disposable asset so both read and write paths are exercised. The server is not “started” for household purposes until those normal operations work.

Run a second reboot after the first successful test to make sure the result was not cache luck or a one-off network timing event. If startup remains inconsistent, preserve the boot traces and focus on the component whose readiness varies between runs. Do not hide variability with a longer fixed delay unless you have no better readiness signal.