Make.com Error Handling Tutorial: How to Build Automations That Fail Gracefully

Every production automation fails eventually. An API goes down. A required field arrives empty. A rate limit gets hit at 3am. A third-party service returns an unexpected response format. The difference between an automation that recovers quietly and one that silently drops data or sends corrupted records downstream is error handling.

Most Make.com tutorials cover the happy path. This one covers what happens when things go wrong, how to catch it, and how to design scenarios that keep running even when individual steps fail. If you're new to Make.com scenarios generally, Make.com Tutorial for Beginners is the place to start.

Why Error Handling Is Not Optional

The instinct when building automations is to optimise for the scenario working correctly. Error handling feels like a secondary concern. It is not.

A scenario with no error handling fails silently. You do not know it failed until a lead is missing from the CRM three days later, or a client did not receive a confirmation message they were expecting, or a payment event was not logged. By the time you notice, the trail is cold and fixing the downstream consequence is harder than catching the failure would have been.

A scenario with proper error handling fails loudly and specifically. You know which module failed, why it failed, and what data was involved. In many cases, the scenario handles the failure automatically and continues without any data loss. In the cases where it cannot, you receive an alert with enough context to fix it quickly.

Error handling is the difference between an automation you trust and one you have to babysit.

How Make.com Handles Errors by Default

By default, when a module in a Make.com scenario fails, the scenario execution stops at that module. The modules before the failure ran and their actions may already have happened. The modules after the failure did not run. The failed execution is logged in the scenario execution history.

Make.com sends an email notification for each failed execution by default. You can configure this under your account notification settings.

The execution history shows you the failed run, which module it failed at, and the error message. You can re-run failed executions from the history if the underlying problem has been fixed. This is useful for transient failures like a temporary API outage: fix the issue, re-run the failed executions, and the data flows through correctly.

Default behaviour handles occasional, obvious failures reasonably. It does not handle complex failure scenarios, does not retry automatically, and does not allow the scenario to take a different path based on the type of failure. For that, you need explicit error handlers.

The Three Error Handler Types

In Make.com, you attach error handlers to individual modules. Right-click any module and select Add error handler to see the options.

Ignore

The Ignore handler catches the error, logs it, and allows the scenario to continue from the next module as if the failed module had not existed. No data is passed from the failed module to downstream modules.

Use Ignore when the module that failed is non-critical and its failure should not stop the rest of the scenario. A good example: a Slack notification module that alerts your team about a new lead. If Slack is down and the notification fails, you do not want the entire lead capture scenario to stop. Ignore the Slack failure and continue with the CRM contact creation and the follow-up sequence, which are the critical parts.

Do not use Ignore on modules where the output is required by downstream modules, or where a failure indicates data corruption that should stop processing.

Break

The Break handler stops the scenario at the point of failure and marks the execution as incomplete. Crucially, it places the failed execution in a queue for manual retry or automatic retry after a configurable delay.

Use Break for critical modules where a failure means you need to retry the same operation with the same data once the underlying problem is resolved. API rate limit errors (HTTP 429) are the classic case. The API is not broken, it just needs you to wait before trying again. Break with a retry delay handles this cleanly: the execution waits, retries, and continues if the API accepts the request on the next attempt.

You configure Break behaviour in the module error handler settings: number of retries, delay between retries, and what happens if all retries fail (typically, the execution is marked as failed and you receive a notification).

Rollback

The Rollback handler is for scenarios where a failure partway through means previous actions should be undone. It stops the scenario and attempts to reverse any changes made by modules that use transactions.

Rollback is the most limited error handler because it only works with modules that support transactional operations. Most API calls cannot be rolled back through Make. The practical use cases are narrow: database operations with explicit transaction support, or Make-native operations that support rollback.

For most Make.com automations, Ignore and Break cover the majority of error handling needs.

Building an Error Branch With a Router

Error handlers handle module-level failures. But sometimes you want to take a specific action when a failure occurs — not just ignore it or retry it, but do something different. A Router combined with error handling creates this capability.

Here is the pattern: attach an error handler to a critical module and connect it to a branch that executes alternative logic. For example:

1. HTTP Request module calls the GoHighLevel API to create a contact
2. On success: the main branch continues with the follow-up sequence
3. On failure (error handler branch): a Slack message fires with the error details and the original data, so a team member can manually create the contact

This pattern ensures that a failure in the API call does not silently drop the lead. The data is captured and surfaced to a human who can act on it. This is exactly the kind of safety net worth building into the Retell-to-GHL webhook pattern covered in Make.com Webhook Tutorial.

To build this in Make: right-click the module, add an error handler, choose Ignore, then connect modules to the error handler path. These modules run only when the error is caught. The main path runs when the module succeeds.

The Error Trigger Scenario: Your Global Safety Net

Make.com has a special trigger called the Error trigger. A scenario built on the Error trigger runs whenever any other scenario in your Make account encounters an unhandled error.

This is the most important error handling feature in Make and the most underused. Set it up once and it catches failures across all your scenarios.

The Error trigger scenario receives details about the failed execution: the scenario name, the module that failed, the error message, and the execution ID. You use this data to:

• Post a detailed Slack alert with a direct link to the failed execution in Make
• Send an email to the person responsible for that specific automation
• Log the failure to a Google Sheet or Airtable for tracking
• Create a task in your project management tool for investigation

To set up an Error trigger scenario: create a new scenario, choose Error as the trigger type, configure your notification actions (Slack, email, or both), and activate it. From that point, every unhandled error in any of your scenarios sends you a notification with the context you need to investigate and fix it.

Handling Specific HTTP Status Codes

When your scenario makes API calls, different HTTP error codes mean different things and may warrant different responses.

400 Bad Request. The data you sent was invalid. The API rejected it. This usually means a required field was missing or a value was in the wrong format. The error will repeat on retry. Do not retry — log the error and the data for investigation.

401 Unauthorized. The API key or token is invalid or expired. Retrying will not help. Alert immediately and update the credentials.

403 Forbidden. Authenticated but not authorised for this operation. Usually a permissions issue with the API credentials. Investigate the permission scope.

404 Not Found. The resource you are trying to access does not exist. This is often a logic error — you are referencing an ID that has been deleted or never existed. Log and investigate.

429 Too Many Requests. Rate limit hit. Retry after a delay. Use the Break handler with a retry delay matching the rate limit reset window.

500 / 502 / 503 / 504. Server-side errors. Transient. Retry with exponential backoff. Use the Break handler.

In Make.com, you can inspect the HTTP status code of a failed HTTP Request module in the error handler using {{error.statusCode}}. Use a Router in the error handler branch to route different status codes to different responses. Make.com HTTP Module Tutorial covers the HTTP module fundamentals this builds on.

Testing Error Handling

Error handling that has never been tested is error handling you cannot trust. Test it deliberately.

Force a failure. Temporarily enter an invalid API key in a module's connection, or set a required field to an empty value. Run the scenario manually and confirm the error handler fires as expected.

Trigger the Error trigger scenario. Make a scenario fail intentionally and confirm your global Error trigger notification arrives with the right details.

Test retry logic. If you have a Break handler with retries, reduce the retry count to 1 and the delay to a short interval. Force a failure and watch whether the retry fires and whether it succeeds when you fix the underlying issue.

The API Request Tester is useful here for testing what specific API endpoints return under error conditions — sending a bad request deliberately to see the exact error response format before writing your error handler logic in Make.

Data Validation Before It Fails

The best error is one that never happens. Adding validation steps before modules that are likely to fail catches bad data before it reaches the API call and produces a cleaner failure with more useful context.

Common validation patterns in Make:

Empty field check. Before creating a CRM contact, add a filter that only continues if the email field is not empty. Route records with a missing email to a Slack alert or a Google Sheet for manual review.

Format validation. Before sending an SMS, check that the phone number field matches a basic phone number pattern using Make's text functions. An invalid phone number format will fail at the SMS provider — catch it before the API call.

Duplicate check. Before creating a new record, search for an existing record with the same identifier. Create if not found, update if found. This prevents duplicate record errors from the CRM API.

These validations run fast, cost minimal operations, and prevent a large share of avoidable failures.

Building Automations You Can Trust

Error handling is what separates automation that genuinely runs your business from automation that requires constant supervision. A scenario with thoughtful error handling tells you when something goes wrong, keeps running when it can, retries when it should, and never drops data silently.

Build it into every scenario from the start. Adding it after the fact, once something has already gone wrong in production, is always more painful than designing it in from the beginning. It's a non-negotiable part of every client automation I ship, not an optional extra bolted on later.

If you want help adding robust error handling to your existing Make.com scenarios or building a new automation with error handling designed in, book a free 30-minute call. Bring the scenarios that have caused you problems and we will work through the right error architecture together.