Make.com Error Handling Tutorial

📝 Blog⏱ 5 min read

Make.com Error Handling Tutorial

Errors are inevitable when running Make.com scenarios at scale. APIs go down, rate limits hit, data formats change. This tutorial teaches you how to catch, diagnose, and recover from errors so your automations keep running even when things go wrong.

Understanding Make.com Errors

Make.com categorizes errors into three types:

Error TypeDescriptionCommon Causes
**Data Error**Invalid data format or missing required fieldsMissing required fields, type mismatch, encoding issues
**Connection Error**Cannot reach external serviceAPI downtime, network issues, auth expiry
**Rate Limit Error**Too many requestsAPI quotas, burst limits, concurrent runs

The Error Handler Module

Make.com's Error Handler is a special module that catches errors from any module in your scenario.

Adding an Error Handler

1. Open your scenario 2. Right-click any module → Add Error Handler 3. Choose the error types to catch: - All errors (recommended for beginners) - Data errors only - Connection errors only - Rate limit errors only 4. Connect the error handler to your recovery flow

Error Handler Variables

When an error occurs, Make provides these variables:

VariableDescription
`error.name`Error type (e.g., `DataError`, `ConnectionError`)
`error.message`Human-readable error message
`error.module`Name of the module that failed
`error.bundle`The data bundle that caused the error
`error.timestamp`When the error occurred

Recovery Strategies

1. Retry with Backoff

Best for transient failures (rate limits, temporary network issues).

Setup: 1. Add Sleep module after error handler 2. Set delay: {{ 60 * (attempt + 1) }} seconds (exponential backoff) 3. Add Router to loop back to failed module 4. Use Set Variable to track attempt count 5. After 3 attempts, route to alert instead of retry

2. Fallback Value

Best for non-critical data enrichment (e.g., optional enrichment API).

Setup: 1. Add Set Variable module in error path 2. Set fallback value: {{ "N/A" }} or {{ emptyArray }} 2. Continue scenario with fallback data

3. Alert and Continue

Best for monitoring without stopping the scenario.

Setup: 1. Add Send Email or Slack module in error path 2. Include error details: {{ error.module }}: {{ error.message }} 3. Include bundle data for debugging 3. Use Ignore to let scenario continue

4. Dead Letter Queue

Best for critical data that must not be lost.

Setup: 1. Add Google Sheets / Airtable / Database module in error path 2. Log: timestamp, error details, full bundle data 2. Optionally: create a manual review task in Asana/Trello 3. Stop scenario execution for this bundle

Error Handler Patterns

Pattern 1: API Rate Limit Handling

1. HTTP Request → Rate Limit Error (429)
2. Error Handler → Sleep (60s) → Retry HTTP Request
3. After 3 retries → Alert Slack → Stop

Pattern 2: Data Validation with Fallback

1. HTTP Request → Parse JSON → Data Error
2. Error Handler → Set default values
3. Continue with default data

Pattern 3: Authentication Expiry

1. Any Module → Connection Error (401)
2. Error Handler → Refresh Token (if possible)
3. Retry original module
4. If refresh fails → Alert admin → Stop

Debugging Errors

Using the Execution Log

1. Go to Scenarios → Execution Log 2. Filter by status: Error 3. Click any failed run 4. Click the red exclamation on the failed module 5. Inspect: - Input bundle - Output (error details) - Settings used

Using the Debug Panel

1. Open scenario in editor 2. Click Run Once 4. Click any module to see Input/Output 5. For errors, click Error tab to see full stack

Common Error Messages and Fixes

ErrorLikely CauseFix
`400 Bad Request`Invalid payloadCheck required fields, data types
`401 Unauthorized`Expired/invalid tokenRefresh OAuth, check API key
`403 Forbidden`Insufficient permissionsCheck API scopes, user roles
`404 Not Found`Wrong endpoint/resource IDVerify IDs, check API version
`422 Unprocessable Entity`Validation failedCheck required fields, formats
`429 Too Many Requests`Rate limitedAdd sleep, reduce frequency
`500 Internal Server Error`API bug/downtimeRetry with backoff, alert
`502 Bad Gateway`Upstream service downRetry, check status page
`503 Service Unavailable`MaintenanceRetry with longer backoff
`ETIMEDOUT`Network timeoutIncrease timeout, check connectivity

Alerting and Monitoring

Email Alerts

1. Add Email module in error handler 2. Template: ``` Subject: ⚠️ Make.com Error: {{ error.module }}

Scenario: {{ scenario.name }} Module: {{ error.module }} Error: {{ error.message }} Time: {{ error.timestamp }} Bundle: {{ toJson(error.bundle) }} ```

Slack Alerts

1. Add Slack > Send a Message module 2. Channel: #alerts or #automation-errors 3. Use blocks for rich formatting 4. Include Run Again button with scenario link

Dashboard Monitoring

1. Create a Google Sheet or Airtable error log 2. Every error appends a row 3. Build a simple dashboard in Google Data Studio or Metabase 4. Track: error rate, common errors, MTTR

Preventing Errors

PracticeDescription
**Validate early**Use **Filter** or **Router** to validate data before API calls
**Use defaults**Set default values for optional fields
**Idempotency keys**Pass unique keys to prevent duplicate processing
**Test with bad data**Run scenarios with missing/invalid data during development
**Version control**Export scenario JSON, commit to Git
**Document assumptions**Add notes to modules explaining expected data formats

Advanced: Custom Error Functions

For complex logic, use Custom Functions (JavaScript):

function getDelay(attempt) { return Math.min(1000 * Math.pow(2, attempt), 30000); } ```

Related Guides

Frequently Asked Questions

Right-click any module in your scenario and select 'Add Error Handler'. Choose which error types to catch (Data, Connection, Rate Limit, or All), then connect the error handler to your recovery flow.

Data Error means the data format is invalid (missing fields, wrong type). Connection Error means Make couldn't reach the external service (network, auth, downtime). Rate Limit Error is a separate category for 429 responses.

Add a Sleep module in the error handler path with delay formula `{{ 60 * (attempt + 1) }}` seconds, use a Router to loop back to the failed module, and track attempt count with a Set Variable module. Stop after 3 attempts.

Add an Email or Slack module in your error handler path. Include error details like module name, error message, timestamp, and bundle data. This lets you respond quickly without constantly checking the execution log.

Yes. In the error handler path, use the 'Ignore' directive or simply don't connect a stop module. The scenario will continue with the next bundle. Use this for non-critical steps like optional data enrichment.

Advertisement

Related Articles