Make Scenario Error Handling

A practical field guide from Automation Ace.

Error Handling in Make.com Scenarios: A Practical Field Guide

Every Make scenario will eventually receive unexpected data, hit an API rate limit, or encounter a network timeout. For context on how Make's error handling compares to Zapier's approach, see Zapier vs. Make for business process automation. How you handle those failures determines whether your automation is production-ready or a system that quietly drops records and requires constant manual intervention. Make's error handling tools are sophisticated — understanding them separates scenarios that work in demos from ones that run reliably in production.

Make offers three error handling approaches: error handler routes (graphical error paths attached to modules), the Break directive (stops the bundle and puts it in an incomplete executions queue for retry), and the Ignore directive (skips the failed bundle and continues). Knowing which to use when requires understanding what you want to happen to the data when a step fails.

Error Handler Routes: Controlling What Happens After a Failure

Right-click any module in Make and select "Add error handler" to attach an error route. This route only executes when the parent module throws an error. The first module on the error route receives the error information: the error type, message, module name, and the bundle data that caused the failure.

For a production API call module (sending data to HubSpot, Airtable, or a payment processor), the error handler route should do three things: log the failed bundle data to an Airtable "Error Log" table (so you have a record of what failed and why), send a Slack alert with the error message and scenario name, and (optionally) attempt a retry using a Repeater module with an exponential backoff delay.

The Break, Ignore, Resume, and Rollback Directives

• Break: Stops processing the current bundle and stores it in the "Incomplete Executions" queue. On the next scheduled scenario run, Make automatically retries the stored bundle. Use Break for transient errors — rate limits, temporary API unavailability — where you expect the retry to succeed. Break is only available on scheduled scenarios (not webhook-triggered ones).
• Ignore: Skips the failed bundle entirely and moves on to the next one. Use Ignore when a failed item is truly unrecoverable and continuing the rest of the batch is more important than stopping. Always pair Ignore with an error route that logs what was skipped, or you will lose data silently.
• Resume: Continues execution from the point of failure using a fallback value you specify. A module that tries to fetch a record from Airtable and fails with "record not found" can Resume with an empty object, and the next module can handle the null gracefully. Use Resume when you have a sensible default that makes the rest of the scenario work.
• Rollback: Reverts all operations made in the current execution and marks it as an error. Available only when using Make's transaction-capable modules. Use for scenarios where partial writes would leave data in an inconsistent state.

The most common Make error handling mistake is attaching a Break directive to a webhook-triggered scenario — Break only works for scheduled runs. Webhook scenarios that fail simply error and the webhook payload is lost unless your error route captures it explicitly.

Handling API Rate Limits Gracefully

Rate limit errors (HTTP 429) are the most common class of transient error in Make scenarios that process large batches. The fix is a combination of a Repeater module and a Sleep module on the error route. When a 429 error hits: the error route's Repeater tries the request up to 3 times, with a Sleep module adding an increasing delay (5 seconds, 15 seconds, 45 seconds) between retries. If all retries fail, the Break directive stores the bundle for a later retry when the rate limit window has reset.

For Google Sheets API (100 requests per 100 seconds), Airtable API (5 requests per second), and HubSpot API (10 requests per second on free tier), build the sleep delay into the normal scenario flow — not just the error path. A Sleep module after every 5 Airtable writes prevents the rate limit from being hit in the first place.

Building a Central Error Log in Airtable

Create an Airtable table called "Automation Error Log" with fields: Scenario Name (Text), Module Name (Text), Error Type (Text), Error Message (Long Text), Failed Bundle Data (Long Text, store as JSON string), Timestamp (Date), Status (Single Select: New / Investigating / Resolved). Every error handler route in every production scenario should create a record in this table as its first step. This gives you a single place to see all automation failures across all your Make scenarios, without logging into each scenario individually.

Testing Error Paths Before Going Live

Test your error handlers deliberately before deploying a scenario to production. Use Make's "Run Once" mode and intentionally trigger error conditions: send a malformed payload to the webhook, reference a non-existent Airtable record ID, use an expired API key. Confirm the error route fires, the Slack alert arrives with the correct message, and the Airtable error log record is created with the right data. If you discover the error path was never tested until a real failure occurs, the error handler often has its own bugs.

1. Add an error handler route to every module that makes an external API call (HTTP, Airtable, HubSpot, Google Sheets, etc.).
2. Configure the error route to write to an Airtable Error Log table and post a Slack alert as the first two steps on every error path.
3. For transient errors (rate limits, timeouts), add a Repeater + Sleep retry loop before escalating to Slack.
4. Choose Break for scheduled scenarios with retryable failures, Ignore with logging for skippable items, and Resume with defaults for recoverable null values.
5. Set up Make's "Incomplete Executions" review as a weekly task so stored bundles do not accumulate unaddressed. For the broader monitoring and maintenance framework that supports these practices, see automation maintenance and monitoring. For Make-specific webhook patterns that need solid error handling, see Make.com webhook automation examples.
6. Test every error path intentionally before the scenario goes live — never assume the error handler works until you have seen it fire on a real error.