When Is an Immich Warning Safe to Monitor, and When Should You Stop?
An Immich warning is safe to monitor when it is bounded, the affected operation still completes, useful work continues, and there is no evidence of database, filesystem, mount, or memory failure. Stop new writes when the same warning repeats with failed operations, disappearing storage, OOM kills, database recovery errors, or rapidly worsening resource pressure.
The word “warning” is not the decision. A harmless retry message and a “no space left on device” message can both appear during a busy import, but they imply very different risk. Capture the first timestamp, the exact operation, the affected asset or job, and the state of storage and containers before restarting anything.
Classify the Warning by the Operation It Can Break
Start with one concrete user action: upload a test photo, open an old asset, run one search, or observe the background job that produced the message. Match the warning timestamp to the Immich server, machine-learning service, PostgreSQL, reverse proxy, and storage logs. The question is whether the warning belongs to a successful request, a retried request, or a failed write.
A log-level severity guide is a useful starting point: WARN commonly means an unexpected condition the application may still survive, while ERROR signals a failed operation. Immich troubleshooting still has to map that label to the affected request, write path, or dependency before deciding whether continued use is safe.
If the same action succeeds repeatedly and the warning count stops growing, classify it as a monitor branch until evidence changes. Record the normal rate and context so you can tell whether a future version, library change, or capacity problem makes the message more frequent. One isolated message without user-visible impact is not enough reason to rebuild the stack.
The ZimaSpace decision framework for repairing versus rebuilding Immich uses the same boundary: preserve state and diagnose a localized fault before replacing a working deployment. A warning becomes more important when it expands beyond one operation or returns after the matched cause is repaired.
Keep Monitoring When Progress and State Remain Healthy
A monitor-only warning has a stable envelope. The queue continues to fall after arrivals stop, retries eventually succeed, database queries remain normal, free space stays above the operating floor, mounts remain present, and containers do not accumulate restarts. The user-visible workflow should remain within its normal latency and error range.
Test that boundary rather than assuming it. Repeat the same action five times, include one older and one newly uploaded asset, and compare the warning count before and after. If a warning appears once during model loading or a transient dependency retry but the next attempts are clean, document it with the exact version and continue observing. Do not suppress or filter the warning until you know what it means. Silencing a noisy log line removes your baseline and can hide a transition from harmless retries to failed writes. Monitor duration, rate, correlated job failures, and the resource the message names; those dimensions are more useful than severity labels alone.
Stop New Writes When the Warning Reaches a Data-Safety Boundary
Stop uploads and background jobs when warnings indicate a full or read-only filesystem, a missing expected mount, repeated PostgreSQL recovery or write failures, container OOM kills, or a service repeatedly restarting before transactions complete. Preserve logs and current data paths before creating space or changing ownership.
A database-related “no space left on device” message is not ordinary log noise. An Immich failure discussion combined broken timeline behavior with PostgreSQL space errors during a problematic deployment.
The case does not establish one universal root cause; it shows why storage-related database warnings deserve immediate scope checks before more writes are accepted.
Apply the same stop rule if the host starts swapping uncontrollably, files appear under an unexpected empty mount, or new uploads land in a container writable layer because the intended storage did not mount. Continuing to write can turn a recoverable configuration problem into a larger reconciliation problem.
Make One Reversible Fix and Reproduce the Original Trigger
Correct only the confirmed cause: restore the intended mount, add safe free space, reduce one job's concurrency, fix a failed dependency, or repair a permission boundary. Do not clear all queues, delete database files, prune unknown Docker volumes, and upgrade versions at the same time; that destroys the evidence needed to judge the result.
Restart only the affected service if needed, then repeat the exact trigger that produced the warning. A pass means the user action succeeds, the warning stops or returns to its documented harmless rate, queues drain, storage and memory remain healthy, and a second restart does not recreate the failure. Escalate instead of continuing experiments when the message survives a clean reproduction, database integrity is uncertain, required files disappear, or the first safe repair does not restore normal progress. Provide the exact Immich and PostgreSQL versions, timestamped logs, filesystem state, container restart/OOM status, and one minimal reproduction so the next step can target the failing layer.
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.
