#119 · 3 AI Agency Retainer Options You Can Steal Today

youtube ↗AI & Automation

How can I avoid the 45‑minute timeout in Make when processing many leads, and should I split the scenario?

Sure. Let me walk you through the solution. Your current scenario loops over an input—say a thousand records—using a built‑in iterator and then feeds each record into an AI module that takes several seconds to run. At 5 seconds per execution, you’d hit the 45‑minute timeout after roughly 600 runs, which makes the whole process take a very long time. The fix is to split the scenario: instead of processing everything in one long loop, have the iterator immediately send each record to an external service via an HTTP webhook. The webhook executes almost instantly (around 0.001 seconds), so you can process millions of records within the same timeout window. In practice, you can create a small JSON array, iterate over it, and for each item make a webhook call that triggers the AI module on a separate scenario. This way the sender scenario finishes quickly, and the receiver scenario handles the AI work without ever hitting the timeout. You can also use Make’s sub‑scenario feature or a dedicated Make.com module, but webhooks are the simplest and most reliable method. Just ensure your Perplexity search and ChatGPT modules are placed in the receiving scenario, and you’ll avoid the timeout entirely.

make.comtimeoutwebhookautomation

Related answers

youtube ↗AI & Automation

My Make.com automation slows down and eventually stops when processing about 350 rows; how can I improve performance and avoid timeouts?

The issue is that you’re iterating over a very large number of modules with a time‑step between each call, which makes the flow take a long time per row. Instead of running everything in one long chain, split the work into two scenarios. First, use an array module to collect all the rows, then feed each row into a second scenario via a webhook. That second scenario runs one row at a time, so each iteration only executes the AI module (or any other heavy module) and then finishes before the next one starts. By processing one record per scenario you keep each run well under Make’s timeout limit (around 40‑45 minutes). You can also reduce the number of modules that require waiting (e.g., avoid unnecessary variable steps) and use the “run a scenario” module to orchestrate the two‑step flow. This approach brings the per‑row runtime down to a few seconds, allowing you to handle all 350 rows without hitting the timeout or exhausting your rate limits.

make.comperformancetimeoutautomation
youtube ↗Cold Email

How long should a cold email campaign last, how can I minimize operations, and how can I make it run properly given long processing time?

The length of a cold email campaign depends on your email volume and number of leads. For example, sending 100 emails per day to 1,000 leads lasts about 10 days (or roughly six days a week adjusted). Campaigns can run as long as you want—I’ve run some on and off for about a year until the lead pool was depleted, so there’s no fixed rule. To minimize operations, note that the process scales linearly with the number of leads (O(N)). With 1,000 leads you’ll perform roughly a multiple of 1,000 operations. You can reduce ops by using Google Sheet scripts or App Scripts to handle personalization automatically, or by leveraging community hacks and tools such as bulk‑adding leads to a sheet or the OpenAI bulk endpoint (which takes about 24 hours). While custom solutions exist, I find the 80/20 approach with Make.com sufficient, spending only $10‑$15. To avoid Make.com’s 45‑minute timeout, split the workflow: instead of running the OpenAI call inside the main scenario, send the data via a webhook to a second scenario that processes it and returns the result. This way each scenario handles one lead at a time, keeping execution time low (e.g., ~45 seconds for 1,000 leads at 10 seconds each) rather than hitting the timeout.

cold emailcampaign lengthopsmake.com
youtube ↗AI & Automation

How should I handle a workflow that takes about 20 hours to execute when the N8N starter plan only allows 5 minutes and the pro plan 40 minutes?

The execution time limit of 40 minutes versus your estimated 20‑hour run clearly doesn’t match. The simplest solution is to split the long‑running part into a sub‑workflow. Use the Execute Workflow node to call another workflow that handles the looping over items. Set up the sub‑workflow with a weight or delay to smooth out API errors and rate limits, and make sure you turn off the option to wait for the sub‑workflow to finish so the main flow continues instantly. This pattern is essentially the same as sending an HTTP request to your own N8N workflow and handling the response with webhooks. It works on both the Pro and even the Starter plan because the heavy lifting happens in the background sub‑workflow.

n8nworkflowsubworkflowautomation
youtube ↗Cold Email

Why does my cold email automation stop after 150-160 rows, and how can I scale it to 3,000 leads?

The automation stops because of a timeout or error around 150-160 rows. Instead of just increasing the timeout (which is a temporary fix), split the automation into a subworkflow that returns instantly, handling queuing and waiting logic in the subworkflow so the parent never worries about timeouts and can process thousands of records.

cold email automationtimeoutsubworkflow