How Much Free Storage Should Immich Keep for Background Jobs?
Immich should keep enough free storage for the largest expected upload batch, the derived files and temporary output it can create, one fresh database backup, and a filesystem safety margin; there is no reliable universal percentage for every library.
A phone-video household, a RAW-photo archive, and a mostly static external library produce very different bursts. Measure a representative job cycle, calculate the peak additional bytes and inodes, then add recovery headroom that remains untouched by normal processing. Configure alerts on absolute free bytes and inodes, because a nominal percentage can be dangerously small or unnecessarily large.
Measure the Library and One Peak Job Cycle
Record the sizes of originals, thumbnails, encoded video, profile data, database backups, and temporary locations before a representative import. Run metadata extraction, thumbnail generation, Smart Search or face processing, and any video transcode expected for that batch, then record the high-water mark.
One user's transcode-heavy case reported storage growing from roughly 100 GB to 326 GB. That deployment-specific growth example shows why media mix must be measured; it is not a general multiplier.
Repeat with the largest realistic family upload, not a single photo. Pass means every relevant path and filesystem is included. If temporary files live on the container root or a separate volume, measure that capacity independently rather than relying on the library disk's free space.
Calculate a Reserve From Named Components
Use a planning equation: reserve equals peak ingest batch plus measured derived-and-temporary growth plus the largest scheduled backup overlap plus filesystem and recovery margin. Document each number and recalculate after changing video policy, model, library size, or backup process.
An independent Immich storage-planning article separates originals, generated files, database activity, and growth planning. Use that framework as context, then replace generic estimates with your own measured high-water mark before setting alerts.
Do not count reclaimable snapshots or pending deletions as guaranteed free space until the filesystem reports them free. Reserve must also cover rollback and log collection after a failed job, so normal queues should never be allowed to consume the final recovery margin.
Alert on Bytes, Inodes, and Growth Rate
Set a warning above the calculated reserve and a critical threshold that stops discretionary imports or reprocessing before writes fail. Monitor absolute bytes, percentage, inode availability, snapshot growth, and the mount identity so a disconnected share cannot report misleading local capacity.
Track rate of change during queues as well as the current total. A fast-growing transcode or backup can cross the reserve between daily checks. Alert messages should name the filesystem and active job rather than simply saying Immich storage is low.
The ZimaSpace article on home NAS storage capacity helps place free-space warnings within a broader growth and expansion plan.
Validate the Threshold and Define Expansion Timing
In a controlled window, start with free space safely above the warning and run the peak batch plus scheduled backup pattern. Pass requires all jobs to finish, backups to complete, and remaining space to stay above the recovery margin without inode exhaustion.
Trend the reserve consumption monthly. Expand, move capacity-heavy media, or change retention before forecast free space reaches the warning within the procurement lead time. Do not wait for the critical threshold to order storage.
Stop new uploads or optional reprocessing if free space approaches the critical boundary, but preserve database and logs. Roll back policy changes that delete needed originals or the last verified backup. Escalate when reported usage does not match path-level measurements, because snapshots, deleted-open files, or a missing mount may be hiding the writer.
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.
