Why Does an Immich Server Run Hot or Noisy During Idle Hours?
An Immich server often runs hot or noisy during idle hours because user-facing activity has ended while queued thumbnails, video transcodes, machine learning, library scans, backups, or failed storage retries continue in the background.
First prove which process, container, job, and device is active at the same timestamp as the fan change. Productive queue drain should show falling job counts and eventually settle; a retry loop repeats errors without progress; a cooling problem can keep fans high after compute and I/O fall. Those branches need different fixes, so do not disable all background work from sound alone.
Correlate Noise With Process, Job, and Device Activity
Log CPU by process and container, temperatures, fan speed, disk utilization, network traffic, and Immich job counts across the noisy window. A pass identifies a resource spike and its owner; if all workload metrics are low while temperature stays high, inspect cooling and sensor control instead.
A large-library discussion describes facial-recognition work making a server loud at recurring times. The job-and-fan correlation is a bounded household example, not proof that facial recognition owns every overnight spike.
Compare the start time with recent uploads, scheduled scans, backup windows, and host maintenance. If noise follows an import and queue depth falls, it is deferred work. If it starts at a fixed time with no uploads, follow the scheduled service that wakes first.
Distinguish Useful Processing From a Retry Loop
Inspect the active queues for thumbnails, metadata, Smart Search, faces, and video transcodes. Productive work completes items and reduces the remaining count. Repeated processing of one item, stable queue depth, container restarts, or recurring dependency errors indicates a fault rather than normal backlog.
One user report described unusually high CPU across many cores on an Immich system. Its high-CPU investigation supports capturing job and process evidence before assuming that core count or idle appearance defines normality.
For a failing asset or dependency, preserve the error and test a small retry after correcting the cause. For valid long-running work, cap concurrency or move it to an acceptable window, then confirm the queue still reaches zero before the next batch.
Check Storage Retries, Scheduled Work, and Cooling
Look for a missing network share, full filesystem, slow disk, backup overlap, database maintenance, container log growth, or repeated library scan. These can drive disk seeks and CPU without obvious web clients. A stable mount and advancing job pass; repeated timeout lines map to storage or network repair.
After workload ends, temperature and fan speed should trend down according to the hardware's thermal mass and control curve. Clean blocked airflow, verify fans and heatsink contact, and inspect the host fan policy only after software activity is excluded. Do not set an unsafe silent curve to mask sustained heat.
The ZimaSpace article on AI NAS photo organization gives context for why local recognition and indexing may continue after uploads finish.
Apply the Matched Fix and Verify Overnight
Schedule or limit only the confirmed heavy queue, resolve the storage or dependency retry, separate backup windows, or repair cooling. Record the old setting and avoid clearing job history before the new behavior is observed.
Repeat the original import or wait through the same schedule. Pass requires expected queue progress, no repeating error, acceptable peak temperature, and return to normal noise after work completes. Restart the server once to verify that schedules, limits, mounts, and fan control persist.
Roll back a concurrency reduction if the queue never clears, and stop compute if temperature exceeds the hardware limit or cooling fails. Escalate with synchronized graphs, job counts, first repeated error, media type, versions, and cooling observations when heat persists after workload reaches zero.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
