Sizing an n8n Wait-and-Poll Loop for a Video That Takes Hours to Render

One channel's weekly explainer is a 10 to 15 minute video generated end to end by a self-hosted render service. Doing that inside a single SSH node would hit a timeout long before the render finished. The workflow starts the job and checks on it instead. The interesting part is choosing the numbers.

Why not one long command

A single SSH command that waits for the render would sit inside one session for hours, and long commands do get cut off: the article on exit code 124 is about a 17-minute render killed exactly that way. Starting the job and polling it turns one fragile long call into many short ones. Each poll in the run below took roughly 0.4 seconds.

Two things the render tool couldn't do at this length

Its built-in script generator tops out below three minutes of video (2 minutes 47 seconds in my test, even with the paragraph count raised), so a Groq step writes the full script and hands it to the tool. And the tool's text-to-speech call had a 30-second timeout that a script of about 2,000 words always exceeded, failing three retries in a row. Raising that timeout in the tool's config file to 240 seconds and restarting its container fixed it. The setting is shared by every channel using the same tool, but their short scripts never came near 30 seconds, so nothing else changed.

The loop

Start render (SSH) -> Wait 20 min -> Poll status (SSH) -> Parse status (Code)
   -> IF ready?  yes -> caption pass -> thumbnail -> append to queue
                 no  -> IF attempts >= 20?  yes -> alert + release the topic
                                            no  -> attempts + 1 -> back to Wait

Choosing the numbers

The ceiling is the poll interval times the maximum attempts: 20 minutes x 20 = 400 minutes, about 6.7 hours, chosen so a render started in the morning still finishes the same day. The first hand-run render of a 15-minute script took roughly two and a half hours of wall-clock time, so the ceiling is well over twice the longest render I had seen. A channel with short renders uses a threshold of 4 instead. A coarse interval keeps the load negligible, and a tighter one would only save minutes on a job measured in hours.

What a real run looked like

The scheduled run on September 17 started at 07:00 and finished at 08:22 UTC. The Groq script call took 4.3 seconds. The Wait node executed four times, 80 minutes of waiting in total, and the caption burn afterwards took under a minute. Render time depends on script length and how long stock-footage downloads take, so a render finishing well inside the ceiling is normal. The ceiling exists for the bad day.

Two details that keep the loop honest

n8n stores longer waits in its database rather than holding them in memory, so a restart of the n8n process during the wait should not lose the run.
The exit path matters as much as the happy path. When the attempt limit is hit, the run alerts and releases the topic back to the queue, following the rule in the claim-at-pickup article.