Make.com Error Handling

Why Error Handling Matters

A scenario without error handling is unreliable automation. When a module fails:

• Without error handling: the execution stops, the data is lost, and nothing notifies you
• With error handling: the error is caught, logged, the team is notified, and the scenario may retry

For production automations processing real business data — customer records, orders, payments — silent failures are unacceptable. Every Make.com scenario running in production needs error handling.

How Make.com Error Handling Works

Every module in Make.com can have an error handler route — a special connection that only activates when that module fails. The error route receives the error data (error type, error message, the bundle that caused it) and you can do anything with it: log it, alert someone, retry, or transform the data and resume.

Adding an error handler: Right-click any module → "Add error handler" → choose the handler type.

Error handler types in Make.com:

The right choice depends on whether the failed operation is critical and whether the data can continue safely without it.

The Standard Error Handling Pattern

For most production scenarios, this pattern is reliable:

1. Add an error handler to every critical module (API calls, CRM updates, database writes)
2. The error handler: Break (stop this bundle) + route to an error logging module
3. Error logging: Write to an Airtable "Error Log" table with: scenario name, module name, error message, timestamp, and the data that caused the failure
4. Slack alert: Post to #automation-errors with key information

This pattern means:

• Errors don't go unnoticed (Slack alert)
• You can investigate later (Airtable log with full error context)
• Other bundles continue processing (Break only stops the failing bundle, not the whole execution)

Retry Logic

For transient errors (network timeout, rate limit 429), retry is appropriate. Make.com has built-in retry configuration:

1. Add error handler to the module
2. In the error handler, check the error type or HTTP status code (Filter: error.statusCode = 429)
3. Use Resume as the handler type
4. The module will retry according to Make.com's built-in retry behavior

For rate limiting specifically: add a Sleep module in the retry path before attempting again. A 60-second sleep before retrying a 429 error is usually effective.

Custom retry with loop: For precise control, build a retry loop using a Router and counter stored in a Data Store. Check the counter, if less than 3, increment and try again; if 3, log the error and alert.

HTTP Module Error Handling

For HTTP modules (API calls), errors come as HTTP status codes. Handle them specifically:

Checking status codes: After an HTTP module, add a Filter checking the response status:

Or use the HTTP module's "Throw an error for HTTP errors" toggle — this causes non-2xx responses to trigger the error handler automatically, rather than passing through as a successful response with error data in the body.

Parsing API error responses: Most APIs return error details in the response body. Extract the error message from body.error.message (the specific path varies by API) and include it in your error log for actionable debugging.

Error Notifications

An error log no one looks at is useless. Build active notification:

Slack alert format:

Route errors to a dedicated #automation-errors Slack channel. Low-urgency errors (retried successfully) → summary; high-urgency errors (data lost) → @mention the on-call team member.

Email alerts for critical errors: For scenarios processing payments or customer data, email alerts ensure errors are seen even if Slack is unavailable.

Testing Error Handling

Build error handling before you deploy — test that your error handling actually works:

Force a module to fail: Temporarily change an API URL to an invalid URL to force an HTTP error. Confirm the error handler activates and the Slack alert/log fires correctly.

Test with bad data: Pass malformed data to a module that would typically fail with it. Confirm the scenario handles it gracefully.

Test retry logic: Configure a test where the first attempt fails and the retry succeeds. Confirm the retry fires correctly.

Recommended Tools

• Make.com — Error handling modules
• Airtable — Error log database
• Slack — Error alert notifications
• PagerDuty — On-call alerting for critical automation failures
• n8n — Alternative platform with similarly strong error handling

“Error handling is the difference between automation you can trust and automation you have to babysit. Every hour you spend on error handling now saves hours of investigation later.”