How long can a workflow execute for

[Isaac_Cheang]

Describe the problem/error/question

I want to create an automation where I can wait for a client to reply to an email, and if they don’t reply for X days then we follow-up. My question is will the workflow time out and is there a more effective way to do this so that the workflows don’t stack up and crash the server?

[achamm]

@Isaac_Cheang it wont time out or stack up, thats exactly what the Wait node is for. any wait over ~65 seconds gets offloaded to the database, so a wait of X days uses basically no resources while its parked, it just sits as a row and resumes when due, nothing stays running in memory. for your follow-up set the Wait to resume on a webhook with a max wait of X days, so a reply resumes it early and otherwise the X-day limit fires the follow-up. only at really high volume would i swap to a state table plus a daily schedule check, but for normal volume the wait node handles it cleanly.

[Anshul_Namdev]

Hello, @Isaac_Cheang.
The old limit of 5 minutes on n8n cloud is no longer in effect, and there is no strict limit in place. However, for self-hosted applications, you can adjust the timeout by setting it to 3600 with the following code: EXECUTIONS_TIMEOUT=3600.
Configure workflow timeout settings | n8n Docs Configure workflow timeout settings | n8n Docs
Additionally, the wait node is not considered a concurrency because it is merely waiting, not executing anything. Additionally, the wait node is not considered a concurrency because it is merely waiting, not executing anything.

@Hasnain_Javed

The active concurrency limit is not affected by the wait node. For example, when a workflow encounters a wait node, the execution is temporarily suspended; it only consumes one of the 50 concurrent execution slots when it is actively processing.. The active concurrency limit is not affected by the wait node. For example, when a workflow encounters a wait node, the execution is temporarily suspended; it only consumes one of the 50 concurrent execution slots when it is actively processing.. Once the wait period concludes and the executions resume, they will once again be counted against your concurrency limit until they either reach the end or encounter another wait. Once the wait period concludes and the executions resume, they will once again be counted against your concurrency limit until they either reach the end or encounter another wait.
The standard and efficient approach for extended waits, such as those lasting up to weeks or months, is to employ a wait node. The standard and efficient approach for extended waits, such as those lasting up to weeks or months, is to employ a wait node. You will not be required to send executions off-platform. You will not be required to send executions off-platform.

If my response was beneficial, please indicate so. If my response was beneficial, please indicate so.
I appreciate it. I appreciate it.

[kjooleng]

@Isaac_Cheang

is there a more effective way to do this so that the workflows don’t stack up and crash the server?

Hi @Isaac_Cheang

Here is the recommended 3-workflow architecture:

Workflow 1: The Initial Outreach

• Trigger: Whatever starts your process (e.g., a new lead).
• Action: Send the first email.
• Action: Create a record in your database with:
  • Client Email.
  • Status: Pending Reply.
  • Follow-up Date: Today + X days.

Workflow 2: The Reply Listener

• Trigger: Email Trigger (Gmail/Outlook) — triggers whenever a new email arrives.
• Action: Search your database for the sender’s email.
• Action: If found, update the record status to Replied.
• Result: This “kills” the follow-up sequence because the status is no longer Pending Reply.

Workflow 3: The Daily Follow-up Checker (The “Cron” Job)

• Trigger: Schedule Trigger (Runs once every 24 hours).
• Action: Query your database for records where:
  • Status is equal to Pending Reply AND
  • Follow-up Date is less than or equal to Today.
• Action: For every record found:
  1. Send the follow-up email.
  2. Update the Follow-up Date to Today + X days (to loop the follow-up if needed).

[Isaac_Cheang]

Thanks @achamm super helpful! Just wondering, what would be considered normal volume for the wait node to work? And would the webhook be responding immediately or after the email node? Thanks again!

[oimrqs_ops]

Normal volume is mostly about the resume burst, not parked waits. Hundreds or a few thousand parked waits are usually fine because they are database rows; the risky case is many records waking at the same minute and hitting Gmail/SMTP/API limits together. If that can happen, spread the due times or run a scheduled batch over a pending_reply table.

For the webhook path, keep it as the reply signal: mark the lead as replied and return fast. The follow-up email belongs on the timeout/due branch, not after the reply webhook, so the person replying is not waiting on an email node.

[Isaac_Cheang]

Hi @kjooleng thanks for this, I’ve set up something similar but I’ve mergered workflow 2 and 3 together so that it just checks for emails every 24 hours and if they haven’t replied yet and the date has been more than 2 days then it will follow up. Is there a reason we need the database?

[kjooleng]

@Isaac_Cheang

Is there a reason we need the database?

If your n8n instance crashes or the server restarts, there is a risk that pending “Wait” executions may not resume correctly depending on your configuration.

Also, instead of making the workflow wait, you should make the workflow check. This is the industry standard for CRM automations. You move the “waiting” logic out of the workflow and into a database (Airtable, Google Sheets, PostgreSQL, or MongoDB). This will conserve server resources at the same time