Facebook's Graph API Said "Unable to Fetch Video File From URL" for a URL That Was Actually Fine

The file was never actually broken

The Portfolio Video Publisher workflow posts short build-breakdown videos — real n8n workflows, explained — to a Facebook Page, an Instagram account, and Threads, once a day. One run failed at the Facebook step with Unable to fetch video file from URL, a Graph API error that means Meta's own servers tried to download the file_url passed in the request and couldn't.

The URL in question, https://phonezait.de/portfolio-videos/system_health_check.mp4, was checked directly after the fact: a plain curl HEAD request returns 200 OK, Content-Type: video/mp4, and a normal content length. Nothing about the file, its path, or nginx's handling of that path is broken. That rules out the two most common causes of this specific Graph API error — a URL that isn't actually publicly reachable, or a file that's missing or corrupted — leaving a transient failure on Meta's end fetching the file at that particular moment as the most likely explanation.

Why "the URL works when I check it" isn't the same as "it worked when Facebook tried"

Facebook's video upload-by-URL flow has Meta's own infrastructure reach out and download the file server-side, separate from and after whatever request Meta's API gateway itself received. That download can fail for reasons that have nothing to do with the source server — a timeout on Meta's crawler, a transient DNS hiccup on their end, temporary rate limiting between Meta's data centers and an external host. None of that shows up as anything wrong from the source side; the server logs a normal successful request whenever anyone actually re-checks the URL, because the URL genuinely is fine by the time anyone looks.

That's the same shape of problem as the Google Sheets 503s covered elsewhere on this site: an external service having a bad moment on one specific call, with no way to reproduce it on demand and nothing actually wrong to "fix" in the usual sense.

The fix: treat it like any other flaky external fetch

The Post to Facebook node had no retryOnFail configured — confirmed by reading its live configuration before making any change. It was updated via the n8n API to retryOnFail: true, maxTries: 3, waitBetweenTries: 3000, matching the pattern already used for the workflow's Google Sheets 503 issue and the Groq rate-limit fix covered elsewhere on this site. If Meta's fetch fails once, the node now gets two more chances, three seconds apart, before the whole publish attempt for that video is marked as failed.

This doesn't fix a bug in the traditional sense — there was nothing wrong with the request, the file, or the hosting — it just stops a single unlucky moment on Meta's infrastructure from silently costing this workflow a day's post on one platform while Instagram and Threads (posted by separate nodes downstream) go out normally.

What confirmed it

The node's configuration was read back from the n8n API after the change: retryOnFail: true, maxTries: 3, waitBetweenTries: 3000 on Post to Facebook. The source video URL was independently re-verified as reachable and correctly served, which is what points at a transient fetch failure on Meta's side rather than anything actually broken here. The workflow was re-fetched and is still active: true.