an error handler is a way to handle errors when they occur during the execution of a Make.com scenario. you can use error handlers to make your scenarios more reliable and flexible.
there are five types of error handlers, and you can set their behavior based on what happens. for example, if you’re autopublishing to Twitter or Blogger and an error occurs due to the API, you can use an error handler.
first, see the photo below, and in the scenario status, if an error occurs in the module, you can use add error handler to add an error handler


option | role | usage |
Break | breaks the scenario immediately | abort execution when an error occurs in a data-integrity-critical operation. |
Commit | complete previous work, abort post-error work | when you need to preserve the results of work before the error. |
Ignore | ignore the error and run the next action | when designing so that when an error occurs, it does not affect the workflow as a whole. |
Resume | retry when an error occurs | when a transient error is likely to have occurred. |
Rollback | cancel all actions and restore to original state | when the operation is transaction-based and the entire operation needs to be canceled in the event of an error. |
1. Break
- role
- stops running the scenario immediately when an error occurs.
- any tasks that were running are terminated, and no further progress is made at the point where the error occurred.
- usage situations
- when a scenario can no longer run due to afatal error.
- when data integrity is critical and you need to stop execution when an error occurs
- example: stopping execution when an error occurs in a financial transaction, database update, etc.
- example
- aborting a scenario when an error occurs while updating customer order data to prevent saving incorrect data.
2. Commit
- role
- any actions executed before the error occurs will **complete (commit) normally**.
- no actions are executed after the error occurs, and previous actions are preserved.
- usage situations
- when you need to preserve the work done in the previous step.
- when you need to ensure that successfully processed data is saved even if an error occurs
- example: If an error occurs in a database update after sending an email, the email remains intact.
- example
- if an error occurs in saving to the database after sending a customer email, but the email action that has already been sent is retained.
3. Ignore
- role
- ignores the error and continues to run the scenario.
- skip the action where the error occurred, and run the next action.
- use situation
- when you need to continue running the remaining tasks regardless of whether an error occurs.
- when the entire workflow should not be affected if an error occurs in a non-essential task
- example: if an error occurs in a log save task, the main process should still run.
- example
- keeping posts uploaded to other platforms even if an error occurs on some platforms while uploading posts to social media.
4. Resume
- role
- retriesthe module where the error occurred.
- retries after waiting a certain amount of time or until the error condition is resolved, which can be repeated a set number of times.
- usage situations
- when an error is likely caused by a transient issue (e.g., network error, API limitations).
- can be used in actions where retries are valid
- example: Retry after a while when an API request fails.
- example
- when a single network error occurs while sending data to an external API, but retrying is likely to succeed.
you can read more about how to use resume in this article.
5. Rollback
- role
- undo **revert** to the state before the error occurred.
- any actions that have already been executed will also be canceled, returning to the original state.
- usage situations
- when you need to ensure data integrity in transaction-based operations.
- when previously processed actions need to be canceled in the event of an error
- example: canceling the entire transfer if some steps in a bank transfer fail.
- example
- rolling back payment data already reflected in the customer’s account if an error occurs while updating object payment information.
summary cleanup
option | role | usage |
Break | abort the scenario immediately | abort execution when an error occurs in a data-integrity-critical operation. |
Commit | complete previous work, abort post-error work | when you need to preserve the results of work before the error. |
Ignore | ignore the error and run the next action | when designing so that an error does not affect the workflow as a whole. |
Resume | retry when an error occurs | when a transient error is likely to have occurred. |
Rollback | cancel all actions and restore to original state | when an operation is transaction-based and you need to cancel the entire operation in the event of an error. |
additional tips
- When setting uperror handlers, consider the importance of the task and the integrity of your data.
- set it up to keep alog recordso that when an error occurs, you can determine the exact cause.
each of the error handling options can also be used in combination for different purposes.