Immich Mobile Backup Stalls or Uploads Keep Failing

Confirm genuinely absent expected originals or an explicit mobile backup or sync failure. Skipped duplicates and accepted uploads with missing derivatives are different observations.[2]

• Yes, missing originals or backup failure → Is the asset actually absent, not skipped or excluded?
• No, a different observation → Investigate the actual Immich observation

Check album selection, exclusions, and whether the checksum already exists server-side. A skipped duplicate ends the failure reasoning for that asset.[2]

• Yes, genuinely absent → Does the upload also fail with the app open?
• No, skipped by selection or dedup → Correct selection or accept the dedup skip
• Cannot confirm absence → Collect an upload failure evidence packet

Compare an observed foreground attempt against background behavior. Foreground success with background stalls isolates mobile OS constraints; foreground failure continues toward path comparison.[2]

• Yes, foreground fails too → Does the same asset work over trusted LAN but fail through the proxy?
• No, only background stalls → Satisfy the background backup conditions
• Cannot confirm the comparison → Collect an upload failure evidence packet

Test the same account and asset over an existing trusted LAN path and through the proxy with synchronized evidence. A proxy-only failure selects the proxy branch; failure on both continues to server evidence. Never open a new insecure port for this comparison.[3]

• Yes, LAN works but proxy fails → Correct the responsible proxy hop
• No, both paths fail → Does the evidence show storage failure or a dependency failure?
• Cannot confirm the comparison → Collect an upload failure evidence packet

Read mounts, access, capacity, and integrity output against the exact failed quota, database, or queue operation. Storage evidence selects the storage handoff; a named operation failure selects the dependency handoff; accepted uploads with missing derivatives exit to the post-upload diagnosis.[6][5]

• Storage failure evidence → Hand storage evidence to the operator
• Quota, database, or queue failure → Hand the exact failed operation to the operator
• Accepted upload, derivatives missing → Exit accepted uploads to the post-upload diagnosis
• Cannot classify the evidence → Collect an upload failure evidence packet

Select the album or remove the mistaken exclusion, or accept the checksum-matched skip as normal. Verify the asset server-side afterwards.[2]

Grant the documented OS permissions and meet the charging, Wi-Fi, and capacity conditions, then verify with an observed background cycle rather than a timer assumption.[2]

Correct the responsible hop's limits, timeouts, TLS, headers, or routing within documented bounds, treating example values as comparison references only. Retest the same asset through the proxy afterwards.[3]

Hand measured mounts, access, capacity, and integrity evidence to the operator for repair under backup protection. Never create markers on unmounted volumes.[6]

Hand the exact failed quota, database, or queue operation with dependency health to the operator. Never flush Valkey and never equate the failure with corruption.[5]

An accepted original with missing derivatives belongs to a separate post-upload processing diagnosis. Preserve state and logs; do not reinstall.[5]

External-library scans, restore and recovery, and uploads accepted but missing later derivatives each need their own diagnosis.[2]

Preserve versions, asset and album state, foreground and background behavior, the LAN-versus-proxy comparison with synchronized logs, and storage and dependency evidence. Send the sanitized evidence to the operator.[1][2]