I have a n8n automation which have loop over items node with batch size 1. so lets say we got 100 items to loop over items node and somehow due to some circumstances workflow failed when it was processing 49th item. what will happen if I retry the workflow? it will start executing from failed node and 49th processing item or it will restart entire workflow from start?
I happened something similar , the solution was easy , you only need change settings of your loop over item node, and activate try again whether fail, and well this can be a solution if you don’t have node in charge to do it something within process.
To directly answer your question: when you retry a failed workflow in n8n, it restarts from the beginning of the workflow, not from the failed node. There’s no built-in checkpoint/resume functionality for mid-run failures.
So in your scenario with 100 items and a failure on item 49: a retry will reprocess all 100 items starting from item 1.
There are a few ways to handle this:
Option 1: Track processed IDs externally
Before the Loop Over Items node, check a database (Postgres, Supabase, even a Google Sheet) for already-processed IDs and filter them out. Each successful iteration writes its ID as “done.” A retry naturally skips already-processed items.
Option 2: Use continueOnFail on the problem node
If the failure is in a specific node (not the loop itself), enable continueOnFail: true on that node and route errors to a separate branch. The loop continues through all 100 items; failures get logged without stopping execution. You can review/reprocess the failed items separately.
Option 3: Sub-workflow per item
Call a sub-workflow for each item instead of processing inline. If the sub-workflow fails, only that item is affected. The parent loop keeps moving. More overhead to set up but much more resilient at scale.
Option 2 is the simplest fix if the failure is predictable. Option 1 is the most reliable for true idempotent processing.
Thank you this helps. But my use case is kind of like this. My workflow is schedule based. Let’s say it runs for every one hour. So currently iam waiting all items into database once scheduled workflow starts. Once items are written into db then I have a loop over items node which processes item by item in loop. This would stop next scheduled workflow to pick up same items which were picked up in earlier scheduled workflows. But the problem is if something failed inside loop then the items which were already into db won’t get picked up in next scheduled run hence they won’t get processed. So iam thinking of way to solve this. Any idea is highly appreciated
Yeah so the trick here is a status column in your DB table. Right now you’re basically marking items as “I touched these” when you write them, but you have no way to tell the difference between “processed successfully” and “started but crashed halfway through.”
Add a column like status with these values:
pending = new item, hasn’t been touched yetprocessing = loop picked it up, working on itdone = finished successfullyfailed = something brokeThen your loop query changes to: pull everything where status is pending OR failed. That way your next scheduled run automatically retries anything that broke, and skips everything that already went through fine.
Inside the loop itself:
processingdonefailedYou might also want a retry_count column so you can cap it at like 3 attempts. Otherwise if something is permanently broken it just keeps failing every hour forever.
One edge case to watch out for: if the whole workflow crashes hard and the error handler never fires, you’ll have items stuck in processing permanently. A simple fix for that is checking for items that have been processing for longer than, say, 10 minutes and resetting them to failed. But honestly that almost never happens in practice.