Make.com timeouts and limits: what each error means and how to fix it

"Scenario execution time exceeded" (ExecutionInterruptedError)

What happened: one run of the scenario lasted longer than your plan allows. The module that was working at that moment outputs ExecutionInterruptedError. The run ends with a warning, and the bundles that hadn't been processed yet are skipped. Make keeps scheduling later runs, so the scenario stays on. The catch is that this error doesn't create an incomplete execution, so there's nothing to retry. You have to find out which items were missed yourself (Help Center: "Errors that don't create incomplete executions").

Typical causes:

• a search that returns hundreds or thousands of rows
• an Iterator over a big array, followed by several modules per item
• a Sleep module inside a loop
• a slow API that is called once per item

Fixes, in the order to try them:

1. Process fewer items per run. Lower the Limit in the search or trigger module, and let the schedule pick up the rest on the next run. Add a status column such as "Processed" and filter on it, so each run continues where the last one stopped.
2. Batch the calls. If the app's API accepts many records in one request, build the batch with an aggregator and send it in one HTTP call. Make's Help Center suggests this, and it saves credits too. Iterator vs Aggregator explains the pattern.
3. Split the scenario. Hand the slow part to a second scenario with Scenarios › Call a scenario. In asynchronous mode the parent continues right away instead of waiting. Make's subscenarios docs say scenarios started through the Scenarios app don't use credits for the call itself, and the pricing table lists subscenarios on every plan, including Free. We haven't confirmed how Make counts run time when the parent waits in synchronous mode, so use asynchronous mode for the heavy part. A webhook between two scenarios also works, but every call uses credits.
4. Remove waits. A Sleep module (at most 300 seconds) inside a loop adds up fast. Use a slower schedule instead.

Upgrading from Free raises the limit from 5 to 40 minutes (pricing table). That helps a scenario that is close to the limit, but not one that has to process more each month.

ModuleTimeoutError: "The operation timed out"

What happened: a module sent a request and the app didn't answer in time. Make's Help Center says most modules wait up to 40 seconds, and some up to 60, before giving up. The usual cause is a slow or overloaded service on the other side, or a request that asks for too much at once.

• Turn on Store incomplete executions in the scenario settings. Make's Help Center lists ModuleTimeoutError, ConnectionError and RateLimitError as errors it retries automatically. It retries after 1 minute, then at growing intervals: 10 and 30 minutes, then 3 hours, for 8 attempts over about 8 hours.
• Or add a Retry error handler to the module. By default it makes 3 attempts, 15 minutes apart. Make's errors page describes it as retrying "with delays of 5, 10, and 15 minutes", so check the handler's settings. If every attempt fails, the run is stored as an incomplete execution.
• Make the request smaller: fewer records, a narrower date range, a smaller file.
• Custom apps can have a longer timeout, up to 300 seconds for the whole app. Make's Developer Hub explains how.

Background on each handler: Make error handling: Skip, Retry, Resume, Rollback, Commit.

HTTP module timeouts and 504 Gateway Timeout

The HTTP app's Make a request module has an advanced Timeout setting in seconds, from 1 to 300 according to its docs. If an API needs a long time, for example to generate a report, raise it there. Above 300 seconds, use the API's asynchronous pattern instead: start the job, then check its status on a later run, or let the API call your webhook when it's done.

A 504 Gateway Timeout comes from the server you called, not from Make. A proxy in front of the API gave up waiting. Retry it later and make the request smaller.

Webhook responses: when another system calls your Make webhook and waits for an answer, Make waits up to 180 seconds for your Webhook response module (Webhooks app docs, updated 4 August 2026). After that, the caller gets "200 Accepted" instead. If the work takes longer, send the Webhook response first and do the slow part after it.

To have 4xx and 5xx responses treated as errors, so a Retry handler can catch them, set Return error if HTTP request fails to Yes in the HTTP module.

"Max file size exceeded" (MaxFileSizeExceededError)

A module tried to handle a file bigger than your plan allows: 5 MB on Free, 100 MB on Core, 250 MB on Pro, 500 MB on Teams and 1,000 MB on Enterprise (pricing table). Make's own example is moving a file over 100 MB with Google Drive on Core. Without an error handler, the run ends with an error and counts toward the scenario being switched off.

• Don't move the file through Make at all. Pass a link or file ID. For example, ask the app to copy or share the file itself, rather than downloading and uploading it.
• Make it smaller: compress or split it with a PDF or file app before the step that fails.
• Skip oversized files on purpose: filter on the file size before the upload, and log or email the ones you skipped.
• Upgrade if large files are normal for you. Upgrading is the only way to raise this limit.

Webhook payloads have their own fixed 5 MB limit on every plan, so send a file URL rather than the file itself. Related builds: Gmail attachments to Google Drive and PDF automation in Make.

"Scenario is paused (because of exceeded limits)"

This message means the organization has used up a monthly allowance. Make's Help Center describes two fatal errors that switch scheduling off immediately, without waiting for several errors in a row:

• OperationsLimitExceededError: the organization is out of credits. The name dates from when credits were called operations.
• DataSizeLimitExceededError: the monthly data transfer is used up. That's 512 MB on Free and 5 GB per 10,000 credits on paid plans. In Make Community threads, users report Free scenarios paused by data transfer while credits were still left. This is the first thing to check when the credit counter isn't at zero.

Fix:

1. Open your organization's subscription or usage page to see which allowance ran out.
2. Find what used it. Look in each scenario's History for frequent polling, loops, or a webhook that fires more often than expected.
3. Buy extra credits, upgrade, or wait for the monthly reset.
4. Then open each scenario and check that it's switched on again.

Make sends usage alerts at 75% and 90% of your credits (pricing FAQ). Make credits explained shows where credits usually go and has 12 ways to use fewer. The credits calculator estimates a month before you switch a scenario on.

If it isn't the allowance, work through why a Make scenario stopped or was disabled.

Data store full and OutOfSpaceError

Data stores share a storage allowance of 1 MB per 1,000 monthly credits. The Free plan's 1,000 credits give 1 MB, enough for one data store. Each store takes at least 1 MB, and an organization can have up to 1,000 stores (pricing FAQ). When a store or the allowance is full, Data store modules output OutOfSpaceError. The run ends with a warning, the remaining bundles are skipped, and the scenario stays on.

• Delete old records, or give the store more of your allowance: edit the data store and change its size in MB.
• Add a Resume error handler that writes to a backup data store, as Make's Help Center suggests.
• For bigger datasets, keep the data in Google Sheets, Airtable or a database, and keep only keys in the data store.

Incomplete executions storage (10 MB per 10,000 credits, at most 2 GB) can fill up too. If it’s full and Discard data if storage is full (scenario settings) is off, Make switches the scenario off. If it’s on, the failed data is discarded for good. Resolve or delete old incomplete executions regularly.

"Exceeded maximum wait time" when testing a webhook

Make's Help Center doesn't list this exact message. In Make Community threads, it appears when you click Run once on a scenario whose trigger waits for data, such as a webhook, Facebook Lead Ads or another instant trigger, and nothing arrives within about a minute. It isn't a problem with your scenario. Click Run once, then send the test data straight away. Or switch the scenario on and let real data trigger it.