n8n Automation HubWhy split it
Rendering is the slow, expensive half and it's the half that can fail in interesting ways. Uploading is quick and safely retryable. In one workflow, a failure in the upload or thumbnail chain meant reasoning about a run that had already spent its render. After the split the Creator's run takes about half an hour, and the Publisher finishes in well under a minute.
What travels in the row
The queue tab has one row per episode with these columns: row_id, episode_date, status, long_form_path, long_form_title, long_form_description, long_form_tags, chapters_text, thumbnail_source_path, shorts_json, created_at, published_at and youtube_long_id. The shorts_json field holds zero to three shorts, each with its own path, title and publish time.
The chapter list shows why this design matters. In the monolithic workflow the upload node reached back to a Build Chapters node by name. After the split that node lives in a different workflow and can't be referenced at all, so the Creator computes the chapter text and stores it as a literal field in the row, and the Publisher never recomputes it. The earlier version of that reference had already caused trouble once, when a node with no outgoing connections never ran: see the dead-end node article.
Timestamps are absolute
Shorts are scheduled to go public at times chosen when the Creator renders. Those are stored as absolute UTC timestamps rather than offsets such as thirty minutes from now, and the Publisher clamps any time that is already in the past to the present. If the Publisher runs late, a stored offset would drift; a stored absolute time can only end up early, and the clamp handles that.
The key and the buffer
row_id is the episode id, for example ep_20260915, unique per day, so the Publisher's update matches exactly one row. That is the safeguard from the non-unique column article. The Publisher runs two hours after the Creator. The Creator's typical run is about half an hour, so the buffer is generous, and a Publisher that finds no ready row simply exits.
What to watch on the first days
The workflow validated with no errors, but the real test is the queue. Check that a new ready row appears after the Creator's slot, that it flips to published after the Publisher's, and that the video is actually on the channel. The queue on this instance shows that cycle on three consecutive days.
The split also made a later failure easy to see. On a day when the Creator produced nothing, the Publisher had no ready row and exited, which is exactly what a green workflow that produced no episode looks like from the outside.