Handling timeouts gracefully


How do you handle your n8n timeouts gracefully?
Please share tips or lessons you have learnt using n8n!

Describe the problem/error/question

In workflow settings, one can set a timeout period for each workflow.
I find it good to set it for all my workflows, as I have no use case for a workflow to run indefinitely.
I figured out that when the timeout is reached, the Error workflow is triggered. Great!

And then, what do we do?

Please share your workflow

I am building a workflow starting with a webhook trigger, and containing an OpenAI node.
The OpenAI node takes anything between 5 and 25 seconds to return an answer. Above 30000 ms, the node itself times out. At the beginning and end of this workflow, I insert the query and the output into Airtable.

What I’d like to do is to reply to the webhook in case of a timeout. How can I do it?

What I have tried:

  • On the workflow nodes that might error, the complex ones (i.e. not the IF or MERGE nodes), I select in the node settings “On Error (continue using error output)”, which creates another output and allows me to add a “Respond to webhook” node. However, I’m afraid that doesn’t address n8n terminating the workflow because the workflow timeout duration is reached.
  • On the Error workflow triggered, the node “Error trigger” contains the name of the last node of the OW (original workflow) that timed out, which is good. But how can I access more OW data than the default “message:Workflow has been canceled or timed out!”, allowing me to respond to the webhook and to update the correct row in Airtable with a failed status?

Information on your n8n setup

  • n8n version: 1.29.1
  • Database: default: SQLite
  • Running n8n via self-hosted Docker
  • Operating system: Ubuntu

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hey @jb8n,

If a workflow times out there isn’t really a graceful way to handle it at the moment as it happens outside of the workflow execution, What I would probably do in cases where a workflow timeout is possible is implement a different kind of API that you can poll so the first request could return an ID and you could call another endpoint and send the ID to find out if it has finished and get the result or if it failed.

For the node timeout we will be actually putting something shortly that will help with this here; feat(core): Add batching and other options to declarative nodes by janober · Pull Request #8885 · n8n-io/n8n · GitHub

1 Like

Thanks Jon.

I thought that when killing the workflow, n8n could trigger a default “Respond to webhook” workflow, like it can trigger a default “Error” workflow.

I guess it’s a more difficult implementation. Thanks for your suggestion, it’s a bit too complex to set up for the few cases I have.

1 Like