A Make.com scenario timeout happens when a single run goes past Make's maximum execution time and Make stops it. Make enforces a time limit per scenario run, and Make staff on the official community forum have described it as 40 minutes. Long running scenarios usually hit it because they loop through too many bundles, wait on slow APIs, or use Sleep modules to dodge rate limits. The fix is not to make one run last longer, but to split the work: process smaller batches per run, chain scenarios with webhooks, or queue items in a data store and work through them on a schedule.
I see this most when an agency builds a scenario that loops through every client or every row in a big sheet. It works with ten clients and breaks at sixty. This guide covers why it happens, what to check in scenario settings and the patterns I use to fix it.
The Make.com execution time limit
Make limits how long one run of a scenario can last. On Make's community forum, Make staff have stated a 40-minute maximum per run with a short grace period, and that the limit applies to each individual run rather than to your account as a whole. Some users on lower plans have reported runs stopping earlier. Because this is not clearly stated on the public help pages I checked, treat 40 minutes as a ceiling, not a target, and check Make's current documentation or support for your plan.
In practice, if a run is anywhere near that long, the scenario needs redesigning. Long runs are also fragile: the longer a run lasts, the more chances for an API to fail midway.
Why long running scenarios happen
Big iterators
An Iterator splits an array into bundles, and every module after it runs once per bundle. Looping through 2,000 rows with five modules each is 10,000 module runs in one execution. Even at a fraction of a second each, plus API latency, that adds up.
Slow APIs
Some APIs take seconds per call. Reporting APIs, AI model calls and file conversions are common culprits. Twenty slow calls in a loop of 100 bundles is a long run.
Sleep modules
Sleep pauses the scenario to avoid rate limits. Useful in small doses, but a Sleep inside a loop multiplies quickly.
Scenario cycles
If a trigger returns many items and the scenario's maximum cycles setting is high, one execution can process a lot of bundles. The more you process per run, the longer it lasts.
Make.com scenario settings to check
Open the scenario settings and review:
- Sequential processing. When enabled, Make waits for each run to finish before the next starts. Good for order, but a slow run holds up everything behind it.
- Maximum number of cycles. How many times the trigger can loop within one run. Lower it to process smaller batches per execution.
- Allow storing of incomplete executions. If a run fails partway, you can resume it rather than lose it.
- Number of consecutive errors. How many failed runs before Make deactivates the scenario.
- Keep data confidential. Not related to timeouts, but worth knowing: with it on, run payloads are not stored, which makes debugging harder.
On the trigger itself, check the limit on how many records it returns per run, such as the row limit on Google Sheets Watch Rows.
Fix 1: Process smaller batches
The simplest fix. Lower the trigger's record limit so each run handles, for example, 50 items instead of 2,000, and run the scenario more often. The total work is the same, but each run is short and failures only affect a small batch.
This works best when the trigger naturally remembers where it left off, like Watch Rows or most "watch" triggers.
Fix 2: Split into parent and child scenarios
Move the heavy per-item work into its own scenario:
- Parent scenario: gets the list (clients, rows, records) and, for each item, sends a request to the child scenario's Custom webhook with the item ID.
- Child scenario: triggered by its webhook, processes one item: fetch data, call APIs, write results, post alerts.
Each child run is short. The parent run is also short, because it only sends webhooks. If one item fails, only that child run fails, and its error handler can alert you. My Make.com webhooks guide covers the webhook side, including the rate of incoming requests Make accepts per webhook.
Fix 3: Queue work in a data store
When the work is bursty or rate-limited:
- Intake scenario: when items arrive, add each one to a Make data store with a status of "pending".
- Worker scenario: on a schedule, search the data store for a small number of pending items, process them, and set their status to "done" or "failed".
- Cleanup: periodically delete done items to keep storage down.
This gives you control over speed and makes it easy to see what is still waiting. See Make.com scenario variables and data stores.
Fix 4: Aggregate instead of looping
Sometimes you do not need to process items one by one. If you are building a report, use aggregators to combine data and make one call instead of many. If an API supports bulk operations, like adding many rows to Google Sheets at once, use them. Fewer calls means shorter runs and fewer credits. See Make.com Google Sheets for bulk patterns.
Fix 5: Move heavy work elsewhere
If a step is genuinely long, like processing a large file or running a long AI job, consider moving it out of Make:
- Use an external service or function that accepts the job, returns immediately, and calls a Make webhook when done.
- Use n8n self-hosted, where you control execution limits, for workloads that do not fit Make's model. See Make.com vs n8n.
How to find what is slow
- Open the scenario's history and look at a long run.
- Check how many times each module ran. The number on each module bubble shows how many bundles passed through.
- Look for the modules with the most runs and the slowest APIs.
- Fix the biggest multiplier first, usually an Iterator feeding several slow modules.
Error handling for long runs
Even after splitting, things fail. Add error handlers with a Slack alert to the modules that call slow or rate-limited APIs, and use the Retry handler for transient failures. See Make.com error handling. If a run is interrupted, incomplete executions let you resume rather than re-run everything.
A worked example
Illustrative example: an agency has a weekly scenario that loops through 60 clients, pulls metrics from two reporting APIs for each, writes rows to Google Sheets and posts a Slack summary. It works for 20 clients and starts timing out as they grow.
The redesign:
- Parent scenario, weekly: search the client list sheet, iterate, send each client ID to a child webhook.
- Child scenario: fetch metrics for one client, write one row, post that client's summary to their internal Slack channel, with error alerts on API modules.
- Summary scenario, an hour later: read the sheet for this week's rows, aggregate and post one agency-wide digest.
Each run is now short and independent. A failure for one client no longer kills the report for everyone.
How I build this
I redesign long Make scenarios into short, reliable runs with batching, parent and child scenarios, data store queues and proper error alerts. If you have a scenario that keeps timing out, the Automation Rescue fixes it in 48 hours at a fixed price. For reporting at scale, see the Agency Reporting and Alerts Pack. Or request a free 15-minute Loom teardown.
FAQ
What is the maximum execution time for a Make.com scenario?
Make limits the duration of each run. Make staff on the official community forum have described it as 40 minutes, but check Make's current documentation for your plan.
Why does my Make scenario stop before finishing?
Usually it hits the execution time limit because of large loops, slow APIs or Sleep modules. It can also stop on an unhandled error, so check the run history for the cause.
How do I run a long process in Make.com?
Split it into smaller runs: lower the batch size per run, use a parent scenario that sends items to a child scenario by webhook, or queue items in a data store and process them on a schedule.
Does the Make.com timeout apply to the whole account?
According to Make staff on the community forum, the limit applies to each individual scenario run, so several scenarios can run at the same time.