Why Does Immich Return Intermittent Errors During Large Mobile-Library Imports?
Intermittent Immich errors during a large mobile import usually mean one layer is failing under overlap, not that the entire library or every uploaded asset is corrupt.
Large imports combine mobile background behavior, long requests, reverse-proxy or tunnel limits, database writes, storage I/O, thumbnail and video work, and machine-learning queues. Capture a small cohort of failed assets and timestamps first. Then determine whether the failure begins on the phone, the network path, the application server, or a saturated dependency.
Classify the Error Cohort Before Retrying Everything
Group failures by media type, file size, source device, network path, and time. If only large videos fail, investigate request duration and upload limits before CPU. If random photos and videos fail at the same busy intervals, shared server resources or network instability become stronger candidates.
A 2026 Immich user report describing many mobile upload errors is useful because it shows how a large phone backlog can surface repeated failures that need per-item and per-path diagnosis. It does not establish one universal mobile-client bug.
Do not select “retry all” as the first diagnostic action. Save ten failed asset names or IDs, one successful control item, and the corresponding client and server log window. A small known cohort lets you test changes without generating a fresh storm that hides the original evidence.
Compare Local Uploads With the Normal Remote Path
Upload the same small and large test files over stable local Wi-Fi directly to the trusted local endpoint, then repeat through the usual remote hostname, VPN, tunnel, or reverse proxy. Keep account and asset unchanged so the route is the main variable.
A report of large-file backup failures highlights why proxy or tunnel request limits belong in this branch. The reported service and thresholds are deployment-specific; the general test is whether direct local transfer passes while the remote path fails consistently.
If both paths fail on the same assets, follow server and storage evidence. If only the remote path fails, inspect maximum body size, request buffering, idle and read timeouts, TLS termination, mobile network transitions, and retransmissions. Changing thumbnail concurrency will not repair a request that never reaches Immich completely.
Correlate Errors With Queue Growth and Resource Pressure
Large imports can keep accepting uploads while background jobs accumulate. Observe CPU, memory pressure, block I/O latency, database responsiveness, container restarts, and job completions during the failure window. High utilization alone is not proof; the metric must change at the same time as the errors.
The Docker resource-monitoring article on container CPU, memory, network, and disk metrics shows the value of comparing containers instead of reading one host-wide average. On Linux, combine container metrics with host storage and memory-pressure evidence for the same timestamps.
If memory pressure causes container exits, storage latency rises with upload errors, or database response time spikes while the queue stops advancing, lower only the responsible workload or concurrency and repeat the fixed cohort. If resource graphs remain calm, continue to application logs and network-path diagnosis.
Treat Error Rate and Tail Latency as Load Signals
A system may look healthy by average response time while a small percentage of requests time out during peaks. Record the number of attempted uploads, failures, median response time, and slower tail requests across a controlled window. This makes “intermittent” measurable instead of anecdotal.
The load-testing framework in error and latency analysis recommends analyzing status classes, connection problems, distributions, and time-series correlations. You do not need to stress the family library aggressively; use the same analytical structure on the real import rate.
If reducing arrival rate sharply lowers failures while every individual asset succeeds, the current stack lacks headroom for that import intensity. If the same files fail even one at a time, the issue is asset-specific, path-specific, or a deterministic software error rather than generic saturation.
Reduce One Pressure Source and Retest the Same Import Pattern
Choose the safest change predicted by the evidence: lower one background concurrency, pause another heavy container, use the local route, move the import outside a backup window, or correct a proxy timeout. Do not change CPU limits, storage, proxy rules, and app versions simultaneously.
The ZimaSpace workflow for phone photo backup interruptions provides the mobile-side branch: background scheduling, cloud-only originals, and changing network conditions can interrupt uploads even when the server is healthy.
Pass when the fixed cohort succeeds and the same larger import runs with a stable error rate, advancing queues, and acceptable interactive performance. Escalate when failures persist at low load or repeat on identical assets; include client logs, server logs, proxy status, resource graphs, file type and size, and the first failing request.
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.
