When I try to set the delay for retry after fail to something higher than 5000ms in any node, it set it back to 5000ms. I need this though, because some services fail at night for a few minutes or even hours and I need to be able to wait for the next retry longer than 5000ms.
Why is the maximum 5000ms?
Hi @nm5182
that 5000ms snap-back isn’t a bug. it’s a hard limit n8n uses to stop long retries from completely freezing your worker threads.
for waits longer than 5 seconds, you have to build a custom retry loop using a Wait node instead. it safely pauses the execution in the database without hogging system resources.
the quick way to set it up:
Continue (using error output).Thanks for the quick response and the excellent explanation. Makes complete sense. I’ll set it up as you described it. 
@A_A4 oh wait, no. The error happens on a trigger node in my case. I can’t loop back to it. What’s the solution in this case?
@nm5182
that changes things! You can’t loop back to a trigger node since it doesn’t have an input.
Before we try to build a workaround, what exact trigger node are you using?
Are we talking about a Polling trigger (like checking Gmail or an RSS feed every few minutes), a Webhook, or a Schedule trigger that immediately fires off an HTTP Request node?
@A_A4 It’s a G Sheets trigger, but of course from a user’s perspective it would be nice to have a working solution for all failing triggers.
For a polling trigger like Google Sheets, the retry loop approach doesn’t apply — you can’t loop back to a trigger node since it has no input.
The right tool here is n8n’s Error Workflow feature.
Go to Settings → (workflow settings icon) → Error Workflow and point it to a dedicated error-handler workflow. That error workflow fires whenever your main workflow fails (including when the trigger itself throws), and it receives details about the error in the $execution object — which workflow, which node, what the error was.
For Google Sheets trigger failures specifically, those are usually transient API hiccups. The error workflow won’t auto-retry the trigger (n8n’s scheduler will just catch it on the next poll cycle anyway), but it gives you visibility — you can log the failure, send yourself a Slack/Telegram alert, or write it to a database.
If you genuinely need to retry the data processing (not the trigger), you can structure it so the trigger just captures the sheet row and passes it to a sub-workflow via Execute Workflow node — then the sub-workflow is the thing with retry logic.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.