Advanced Error Handling in Make.com: Visual Scenarios That Never Break

Building a visual automation scenario on Make.com is straightforward when everything works. However, in production, APIs fail, rate limits are breached, databases go offline, and incoming data formats shift. By default, when a step in a Make scenario encounters an error, the execution pauses or stops entirely, leaving your processes hanging.

To build reliable enterprise-grade automations, you must implement advanced error handling. In this guide, we'll cover Make's native error handlers and how to use them to create self-healing workflows.

The Default Behavior: Why Scenario Failures Happen

When a module experiences a network issue or validation failure, Make behaves in one of three ways depending on your settings:

1. Immediate Stop: The scenario stops immediately, throwing a red warning badge. Remaining modules are not executed.
2. Deactivation: If a scenario encounters consecutive errors (usually 3 to 10), Make automatically turns off the entire workflow.
3. Queueing (Incomplete Executions): The run is moved into an "Incomplete Execution" queue, where you must manually resolve it.

This default behavior is disruptive for mission-critical flows like payment processing or lead syncs.

The Four Core Error-Handling Directives

Make provides four specialized directive modules to route errors gracefully. To add them, right-click on any module, select Add error handler, and choose one of the following:

[Target Module] ──(Error)──> [Error Handler Directive]

1. `Ignore` (Skip and Proceed)

The Ignore directive silences the error entirely. Make will treat the failed module as if it had succeeded, and proceed with the remaining modules in the branch.

• When to use: Tracking analytics, logging, or non-essential email notifications where a failure won't break the core process.

2. `Rollback` (Abort and Revert)

The Rollback directive immediately stops scenario execution and rolls back any changes made during the current run (if the connected system supports transactional rollbacks).

• When to use: Financial operations or database updates where data integrity is critical and partial entries must be avoided.

3. `Resume` (Substitute Data and Continue)

The Resume directive lets you supply a mock or fallback payload to replace the output of the failed module, allowing subsequent steps to run with valid mock data.

• When to use: If an API lookup fails, you can use Resume to inject a default user object or standard pricing structure to keep the process moving.

4. `Break` (Store and Retry Automatically)

The Break directive is the most powerful handler. It pauses the current execution, saves the state, and attempts to rerun the failed step after a specified interval (e.g., every 15 minutes, up to 3 times).

• When to use: Interacting with external web APIs that experience temporary downtime or hit rate limits (e.g., standard HTTP 429 or 503 codes).

Step-by-Step: Setting Up an Auto-Retry Flow

Let's configure a Break directive on a webhook-to-database scenario to handle database outages:

1. Right-click on your Google Sheets (Add a Row) module.
2. Click Add error handler.
3. Choose the Break directive.
4. In the settings panel of the Break directive, configure the retry options:
   • Number of retries: 3
   • Interval between retries: 15 minutes
   • Automatically deactivate scenario on failure: Unchecked (keeps the workflow running).

If Google Sheets experiences a temporary connection issue, Make will queue the run and automatically retry it 15 minutes later, preventing data loss.

Error Directives Comparison Reference

Use the reference guide below to select the appropriate directive for your workflows:

Frequently Asked Questions