How to Set Up Error Handling in Make.com Scenarios

Disclosure: We may earn a commission when you purchase through links on this site, at no extra cost to you. How we make money.

The most dangerous automation isn’t one that fails loudly. It’s one that fails quietly. A scenario that stops halfway through — no alert, no log you think to check, no indication anything went wrong — is worse than no automation at all, because you assume it worked. You might not notice for days. By then, leads have gone uncontacted, data hasn’t been logged, and something that was supposed to run hundreds of times ran zero. Make.com error handling is the discipline that prevents this, and it’s worth understanding before you deploy any scenario you’ll rely on.

Make has a more sophisticated error-handling system than most no-code tools, which is one of its genuine advantages. Here’s how to use it.

What Happens When a Make Scenario Fails by Default

When a module fails — say, a Google Sheets module can’t write because the spreadsheet is shared with the wrong permissions — Make stops the scenario at that module by default. The current bundle doesn’t complete. Any modules after the failing one don’t run.

Make logs the error in your scenario’s history (the clock icon in the scenario editor shows past runs), and if you’ve enabled email notifications, it sends you an alert. But unless you’ve set up error routes, nothing tries to recover or handle the failure gracefully.

For low-stakes workflows, this might be fine. For anything business-critical — customer onboarding, payment processing, lead routing — you want more than a logged error.

Error Routes: The Core Tool

Make’s primary error-handling mechanism is the error route. You add it to any module by right-clicking that module and choosing Add error handler. A red dashed line extends from the module, and you attach modules to it — these modules run only when the primary module fails.

What you do on the error route is up to you. Common patterns:

• Send an email or Slack message: Alert yourself with the error details so you can investigate. Make passes error information (module name, error message, the data that was being processed) that you can include in the alert.
• Log the failure: Write the failed data to a Google Sheet or Airtable row so you can review and reprocess it manually if needed.
• Retry with modified data: In some cases, you can transform the problematic data and try again. For example, if a name field has characters that break an API, clean the string on the error route and retry the module.
• Trigger a fallback workflow: Route the bundle to an alternative path when the primary action fails — perhaps queuing it for manual review instead of dropping it entirely.

Error Handler Types

When you add an error handler to a module, Make gives you three handler types to choose from:

• Resume: After the error route modules run, the scenario continues from the module after the failed one. Use this when you want to handle the error but keep processing the rest of the scenario.
• Rollback: If your scenario supports transactions (database-style operations that can be undone), Rollback reverses any changes made in the current run. This is only relevant for specific module types like Make’s Data Stores.
• Break: Stops the scenario at the failed module but stores the unprocessed bundles, which you can replay later from the scenario history. This is the most common choice for business workflows — you don’t lose the data, you just defer processing until you’ve fixed the issue.

Break is usually the right default. It prevents data loss without requiring you to handle the error programmatically — you can investigate the failure and manually replay the queued bundles once the issue is resolved.

Setting Up Retry Logic

Some failures are transient — an API that was briefly unavailable, a rate limit that momentarily blocked a request. For these, automatic retries are more useful than an immediate error route.

In Make’s scenario settings (the spanner/wrench icon), you can configure Auto commit and Number of sequential errors before the scenario deactivates. For modules that support it, you can also set retry intervals directly in the module settings.

A practical setup: allow 3–5 retries with exponential backoff for API modules that occasionally hit rate limits. If all retries fail, then route to your error handler. This reduces noise from temporary failures while still alerting you to real problems.

Using Incomplete Executions

Make’s Incomplete Executions feature (found in the scenario’s history section) stores bundles that couldn’t be processed due to an error. Think of it as a holding queue for failed data.

To enable it: in scenario settings, turn on Allow storing incomplete executions. When a scenario fails, the unprocessed bundle is held here. Once you’ve fixed the underlying issue (corrected permissions, updated an API key, fixed a data mapping), you can click Resolve all to reprocess every stored bundle without losing any data.

This feature is particularly valuable for payment or onboarding scenarios where losing even one record has real consequences. It’s essentially a safety net you can reach into when things go wrong.

Notification Settings

Even with good error routes in place, you want to know when failures are happening. In Make’s account settings, configure scenario error notifications — you can set them to email you after a module fails a certain number of times, or when a scenario deactivates due to repeated errors.

Don’t rely on checking the scenario history manually. Notifications are what catch problems when you’re not looking.

A Minimal Error-Handling Setup for Any Scenario

If you want a baseline that works for most business workflows without a lot of configuration:

• Enable Incomplete Executions in scenario settings
• Add an error route to your most critical module (usually the one that creates or updates data in an external system) using the Break handler
• Attach a Send an Email or Slack module to the error route to alert you when it fires
• Enable error email notifications in your account settings

That covers the most common failure modes without requiring complex recovery logic. The scenario fails safely, you’re notified, and no data is lost — you process the incomplete executions manually once you’ve resolved the issue.

Error handling is the difference between an automation you can trust and one you have to babysit. Setting it up takes 15 minutes per scenario and gives you confidence that when something breaks — and at scale, something always does — you’ll know about it and be able to fix it without losing the data that was in flight.