Make scenario errors, explained one by one
Last verified
Make (formerly Integromat) labels every module failure with an error type, such as DataError, RateLimitError or ModuleTimeoutError, followed by the message from the app or from Make. The type is what you should read first, because it decides what Make does next and which fix applies. Errors that come from the third-party app's response (DataError, RateLimitError, ConnectionError) are about the app; errors raised inside Make before or around the request (BundleValidationError, ModuleTimeoutError, ExecutionInterruptedError) are about how the scenario is built or how long it runs.
Default handling is where most surprises come from. Without an error handler, Make's default is Rollback: the run stops and ends with an error. After a number of consecutive failed runs (the "Errors before deactivation" setting, three by default according to Make's error-handling overview), Make disables scheduling of the scenario and emails you. Some errors skip the count entirely: instant (webhook) scenarios are deactivated on the first error, and AccountValidationError, OperationsLimitExceededError, DataSizeLimitExceededError and InconsistencyError disable scheduling immediately. RateLimitError and ConnectionError pause scheduling for 20 minutes, or are retried with backoff when "Store incomplete executions" is enabled.
Warnings are different: they do not deactivate the scenario and do not count toward consecutive errors, so they are easy to miss. Each entry below gives the error type as Make shows it, what it means, what is not wrong, and the fixes Make documents, including which error handler (Retry, Resume, Skip, Commit, Rollback) fits.
Official reference: Make Help Center - Fix errors and warnings
How to read a Make error
Open the scenario's History, select the failed run, and click the module with the warning icon. The bubble shows the error type and message:
RateLimitError
[429] Too Many Requests
^ error type: decides default handling
^ status and message from the appIn error handler routes you can map {{error.message}} and related fields to log or notify. Check scenario settings for "Store incomplete executions" and "Errors before deactivation" before deciding on a fix.
All 9 messages
Jump to: Data and validation (3) · App availability and timeouts (3) · Account, connection and plan (2) · Execution limits (1)
Data and validation
App availability and timeouts
| Message |
|---|
| RateLimitError |
| ConnectionError |
ModuleTimeoutError: The operation timed outModuleTimeoutError - The Operation timed out |
Account, connection and plan
Execution limits
| Message |
|---|
| ExecutionInterruptedError |
Definitions
- Make (formerly Integromat)Make (formerly Integromat) is a visual automation platform that connects apps and designs complex workflows us
- Error HandlingError handling is the practice of anticipating, detecting, and responding to errors in software execution, inc
- Rate LimitingRate limiting is a technique that controls the number of requests a client can make to a server within a given
- Retry LogicRetry logic is a fault-tolerance pattern that automatically re-attempts failed operations with configurable de
Make guides, limits and tools
Other error directories
- Cloudflare error pages errors16 messages
- Google Apps Script errors16 messages
- Google Sheets IMPORT functions errors15 messages
- HTTP errors in web scraping and automation errors15 messages
- n8n errors11 messages
- Playwright errors16 messages
- Puppeteer errors15 messages
- Selenium WebDriver errors14 messages
- Zapier errors8 messages
Frequently asked questions
Why was my Make scenario deactivated?
Make disables scheduling after a set number of consecutive failed runs, configured as "Errors before deactivation" in scenario settings. Instant (webhook) scenarios are deactivated after the first error. Fatal errors such as AccountValidationError and OperationsLimitExceededError disable scheduling immediately. Fix the cause shown in History, then switch the scenario back on.
What are incomplete executions in Make?
When "Store incomplete executions" is enabled, a run that fails is saved with its data instead of being discarded. You can fix the problem and resume it, and for RateLimitError and ConnectionError Make retries automatically with backoff. It is the main protection against losing data when an app is temporarily unavailable.
Which error handler should I use?
Retry (formerly Break) for temporary problems such as rate limits, timeouts and incomplete data; Resume to substitute a fallback value; Skip (formerly Ignore) to drop a bad bundle and continue; Commit to stop and keep changes; Rollback to stop and revert. Make's default without a handler is Rollback.
What is the difference between DataError and BundleValidationError?
BundleValidationError is raised by Make before the request is sent, because the module's input failed validation, typically an empty required field. DataError is raised after the request, when the third-party app rejected the data. Fix the former in your mappings and filters; for the latter, read the app's message for the rule that failed.
How long can a Make module or scenario run?
Make documents that modules wait up to 40 seconds for a response, with most modules having a 40 or 60 second limit, after which ModuleTimeoutError is raised. A whole scenario run can last up to 45 minutes on paid plans and 10 minutes on the Free plan before ExecutionInterruptedError.
Do warnings deactivate a Make scenario?
No. Warnings such as ExecutionInterruptedError and OutOfSpaceError end the run or stop processing but keep the scenario scheduled, and they do not count toward consecutive errors. Errors handled by an error handler are also reported as warnings. Review warnings in History regularly, because they can mean data was only partly processed.
How do I get notified about Make errors?
Make emails you when a scenario errors and when it is deactivated, with digests after the first message. You can adjust these under your profile's email preferences. Keep the deactivation notification on: without it, a scenario can stay off for days unnoticed.
Error handling you can see in the workflow
Autonoly workflows have per-node retries, timeouts, continue-on-fail and error-handler branches, so a failing step can be retried or routed instead of stopping the whole run. Saved workflows have no loop node; lists are worked through by the AI agent or one run per trigger item.