What does Make do when nothing is set up?

If you build a scenario without error handling, Make uses the behaviour of the Rollback handler by default. According to Make's help documentation (checked on 13 October 2026), that means: the scenario stops at the error, the run gets the status Error and changes in modules that support transactions are reverted.

It does not end there. Make counts consecutive failed runs:

  • Scheduled scenarios are disabled by default after three errors in a row. You can change that number in the scenario settings.
  • Scenarios with an instant trigger, such as a webhook, are disabled after the first error, according to Make.
  • For a few error types, such as an invalid connection or used-up credits, Make disables the scenario straight away, regardless of the count.

Disabling is meant as protection: you do not want a broken scenario making the same error a hundred times an hour. But the result is that a workflow you rely on suddenly does nothing. Invoices stop being created, leads stop arriving in the CRM, and nobody notices until a customer calls.

Which error handlers does Make have and when do you use each?

In Make you attach an error handler to a module. If that module fails, the scenario follows the error route instead of stopping. Make has five handlers. In older documentation and tutorials you will still find two of them under a different name.

Skip (formerly Ignore)

The bundle with the error is skipped and the rest of the scenario continues. The run ends as Success. Useful when one failed record does not matter, for example a newsletter sign-up with an invalid email address. Dangerous if you put it everywhere: you will no longer see errors anywhere.

Retry (formerly Break)

The failed bundle is stored as an incomplete execution, the rest of the scenario continues and the run gets the status Warning. You can let Make retry the bundle automatically, with a number of attempts and an interval, or restart it manually. This is the handler for temporary problems, such as an API that is briefly unreachable or a limit on the number of requests. Retry only works if storing incomplete executions is switched on.

Resume

You set a substitute value for the output of the failed module and the scenario carries on as if nothing happened. Status: Success. Usable for non-critical fields, for example a default category when a lookup finds nothing. Do not use it for amounts or VAT codes.

Commit

The scenario stops, but whatever has already been processed stays in place. Status: Warning.

Rollback

The scenario stops and Make reverts changes in modules that support transactions. Status: Error. This is also the default behaviour without a handler.

Good to know: according to Make, an error handler that fires does not use credits. Building in error handling does not cost you extra.

Which scenario settings matter for error handling?

Besides the handlers per module, a few scenario-level settings determine how Make deals with errors. You will find them in the scenario settings.

  • Store incomplete executions. When this is on, Make keeps a failed run together with its data, so you can investigate it and start it again. Switch this on for every scenario that deals with money, customers or orders.
  • Number of consecutive errors. Determines after how many failed runs in a row a scheduled scenario is disabled. Three by default. Raising it only moves the problem; better to make sure you see the error in time.
  • Process data in order. With this setting, a new run waits until the previous one has finished and until open incomplete executions are resolved. Useful when order matters, but an unresolved error then also holds up every following run.
  • Keep data confidential. Make then does not keep the content of runs. Good for sensitive data, but according to Make you have very limited options to investigate errors. Make that trade-off deliberately.

How do you make sure someone actually sees an error?

The best error handler does not help if nobody is looking. An error route can contain modules of its own, so use that: put a module at the end of the error route that sends a message to a Teams channel or a mailbox people actually read.

Include at least:

  1. the name of the scenario and the module that failed;
  2. the error message;
  3. which record it concerns, for example the order number or customer name;
  4. what the recipient should do, or where the instructions are.

On top of that, agree on one owner per scenario. Not "the team", but a name. That person looks at an alert within an agreed time, and once a month goes through the incomplete executions and the scenario history. More on ownership and choosing your first processes in workflow automation: 7 processes to automate first.

Example: error handling in an order scenario

A fictional example. A wholesaler with a webshop has Make turn every paid order into a sales invoice in the accounting package. That is scenario 2 from Make.com workflows for SMEs. This is how you set up the error handling:

  1. Switch on incomplete executions. An order that does not go through must never disappear.
  2. Retry on the module that creates the invoice. If the accounting package is briefly unreachable, Make tries again later, for example three times with fifteen minutes in between.
  3. No Resume on VAT or amounts. If the scenario cannot find a matching VAT code, you do not want a default value, you want a person to look.
  4. An alert in the error route. After the Retry handler, the scenario sends a message to the finance team's Teams channel, with the order number and the error message.
  5. A check at the end of the week. A small scheduled scenario counts the paid orders in the webshop and the invoices created in the accounting package. If they differ, an alert follows. That also catches errors that produced no error message, such as orders that fell through a filter.

That last step is often forgotten. A scenario can neatly report Success and still not do what you expect, for example when an API returns an empty list or a filter is too strict. Counting on both sides is then the only way to see it.

Which mistakes do we see most in Make scenarios?

  • Skip everywhere. The scenario always runs green, but records disappear without anyone knowing.
  • Alerts to a personal mailbox. That person is on holiday or has left, and the alerts go nowhere.
  • No stored runs. Without incomplete executions, after an error you have to work out which data was not processed and chase it by hand.
  • The same logic in five scenarios. If several scenarios fetch and transform the same data, you also have to catch errors in five places. A central data foundation is often the better base then.
  • No test with bad data. Do not only test the happy path. Deliberately send a record with a missing field or an unknown customer through the scenario and see what happens.

Not sure whether Make is the right platform for your workflows? Read Make vs n8n.

Need help with error handling in your Make scenarios?

Do you have scenarios running that you are not sure still do what they should, or do you want to set up new scenarios properly from the start? We build Make scenarios with error handling, alerts and documentation, and are happy to look at what is already there. See what we do in workflow automation, which systems we often connect and how we work.