Why Does Immich Cause Repeated Disk Activity Overnight?
Immich can generate repeated disk activity overnight because scheduled maintenance, database work, queued media jobs, or retries continue after people stop using the library.
A quiet household does not mean an idle server. The useful question is whether the same process and job explain the reads or writes at the same clock time. Correlate the activity first, then decide whether it is expected work, backlog catch-up, or a loop that should stop.
Match the Disk Spike to the Clock Before Changing Anything
Begin with three nights of timestamps rather than one noisy observation. Record when block I/O rises, which device is busy, whether reads or writes dominate, and whether the pattern starts at nearly the same time. A repeatable start time points toward a scheduler; an irregular pattern points more strongly toward arrivals, retries, or another container.
Immich deployments can schedule database backups and integrity-oriented work during low-use hours, so an early-morning spike may be deliberate. Do not disable a job only because it wakes the disks. First check whether a corresponding backup, maintenance result, or queue completion appears after the activity window.
The adjacent ZimaSpace diagnosis of Immich idle-hour background work uses the same timestamp rule: connect the visible symptom to the process and job before treating “idle” as a failure state.
Separate PostgreSQL Writes From Media Reads
Immich application state changes can keep PostgreSQL active even when no new photo is being opened. Database checkpoints, write-ahead logging, vacuum-related work, and ordinary application updates have a different I/O signature from scanning thousands of media files. Identify the path or device receiving the traffic before blaming the photo library.
The PostgreSQL observability discussion in pg_stat_io analysis explains why reads, writes, backend activity, checkpointer behavior, and background writes need to be separated. Use that distinction to ask whether the database device is busy because useful transactions are being persisted or because something is repeatedly churning.
If database writes are small and periodic while media disks remain asleep, the behavior may be normal database housekeeping. If the same database file receives sustained heavy writes while no job advances, preserve logs and inspect the responsible queries or restart loop rather than moving the entire library to faster storage.
Check Whether Background Queues Are Actually Advancing
Open the job view and compare pending, active, failed, and completed work before and after the overnight window. Thumbnail generation, video processing, metadata extraction, machine-learning tasks, or imported-library work can legitimately keep storage active after a large change. A falling backlog is evidence of useful catch-up.
A current community report of sustained unexplained reads shows the opposite diagnostic boundary: very high continuous reads with no expected work deserve investigation rather than being normalized as “what Immich does.” Treat the reported rate as a case, not a benchmark.
If the same few jobs fail and re-enter the queue, disk activity can repeat without producing progress. Capture the first error and one affected asset, then isolate that job type. Do not clear every queue or regenerate the whole library before establishing whether the loop is caused by one file, permissions, storage latency, or a service dependency.
Attribute I/O to a Process Instead of Guessing From Drive Noise
Use host-level I/O monitoring during the next recurrence to identify the process that is reading or writing the device. Then map that process to the Immich server, PostgreSQL, machine learning, a backup tool, antivirus, filesystem scrub, or an unrelated container. Drive LEDs and fan noise cannot provide that ownership information.
A practical iotop workflow demonstrates the process-first method. Record several samples because a short burst can disappear between observations; the goal is to catch the process during the same window as the symptom.
If Immich is not the top I/O owner, stop changing Immich settings and follow the actual process. If PostgreSQL, Immich, or a related worker is responsible, correlate its logs and job progress with the I/O sample. That turns “the server is noisy every night” into a specific component and trigger.
Define the Boundary Between Normal Overnight Work and a Fault
Accept the activity as normal when it begins around a known schedule or recent library change, completes useful work, leaves no growing failure count, and returns storage latency and queue depth to baseline. Record the normal duration so a future increase has a comparison point.
A historical Immich discussion about frequent database writes illustrates why some database activity can exist without a visible user action. Because versions and deployments change, use the case only to justify measuring the database separately, not to declare every persistent write normal.
Escalate when I/O continues after queues stop, the same errors recur, storage latency affects daytime use, free space falls unexpectedly, or the pattern grows night after night. Preserve timestamps, process I/O, job counts, relevant logs, filesystem free space, and one repeatable trigger before making invasive changes.
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.
