Build1 publisher2 min readPublished
One unhandled error can switch off a Make.com webhook scenario
Make.com switches off a webhook-triggered scenario after one unhandled error when incomplete-execution storage is off, according to a dev.to guide. In that configuration, the guide rates an unhandled module as the most disruptive error-handling option in Make.
The Engineer · Build desk
What happened
- In May 2026 Make renamed the Ignore error handler to Skip and the Break handler to Retry, and neither one changed how it behaves.
- A scheduled scenario with no handler and storage off gets three errors in a row before Make switches it off, which is the default for Errors before deactivation.
- With Store incomplete executions on, Make keeps the failed run as an incomplete execution and ends it with a warning.
- Rollback and Commit only reach ACID-tagged modules such as Data store or MySQL, so a sent email or a new Google Sheets row stays in place.
- Make's HTTP module treats 4xx and 5xx responses as successes, and runs no handler, unless Evaluate all states as errors is set to Yes.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Monitoring that keys on run status will miss failures absorbed by Skip, or by an HTTP module left on its default, because both finish as a success.
- decision Scenarios that write to Sheets, send email or call external APIs need their own compensating steps, because Rollback cannot undo work in those systems.
- cost Anyone searching exported blueprints or old forum threads has to look for builtin:Ignore and builtin:Break as well as the new names, or the older material will not turn up.
A guide published on dev.to compares a Make error handler to a catch block attached to a single module [3]. When that module throws, Make follows the route attached to it. The handler at the end of the route decides how the run finishes [3]. If there is no route and storage is disabled, Make applies Rollback and stops the run with an error status [4].
Most of the behaviour depends on one scenario setting, Store incomplete executions. Retry will not work without it, and Make flags a Retry handler until the setting is turned on [10]. With Automatically complete execution set to Yes, you choose the number of attempts and the interval between them. With No, the item waits in the Incomplete executions tab until a person deals with it [10]. Storage also turns on automatic retries for ConnectionError and RateLimitError, with no Retry handler attached [13].
I think the new names are an improvement. In the guide's mapping, Retry parks the bundle as an incomplete execution, can retry it a set number of times at an interval, and ends the run with a warning [18]. A handler called Break that saved work for later was always going to confuse someone.
Skip needs watching because it reports success. It drops the failed bundle, stores nothing, and the run still ends as a success. Unless something logs it, nobody sees the failure [8]. An error route that ends with no handler behaves the same way, as long as nothing on the route fails [12]. The guide says a route holding only a Slack alert is a valid pattern [19].
For an API call, the guide sends 429 and 5xx responses to Retry, for example 3 attempts 10 minutes apart. Other 4xx responses are logged and then skipped [15]. If each attempt waits the full interval, that policy covers about 30 minutes of upstream trouble [1]. Retrying a 400 Bad Request repeats the same failure, while a retried 429 often succeeds later [16]. The split only works against an API that returns 429 for rate limits and 5xx for its own faults.
The guide's log row has five columns: time, scenario name, failing module, error message, and an identifier for the item, such as an order ID [17]. The identifier is the column that lets someone fix the data by hand later [17].
What to watch
- Whether Make's blueprint exports replace builtin:Ignore and builtin:Break with identifiers that match the new names.
- What the newer HTTP app calls the option that turns 4xx and 5xx responses into errors, since the guide's label comes from the legacy module docs.
- Any change to the Errors before deactivation default, or to the rule that switches off instant-trigger scenarios after one error.