Error Handling in Make: Stop Your Scenarios from Breaking

If you’ve ever set up a scenario in Make, you’ll know the sinking feeling when it suddenly stops running because of one bad record, a network timeout, or a missing field.

The good news: Make has powerful error-handling features. The bad news: many new users don’t know they exist, or they only discover them the hard way.

In this post, we’ll look at how error handling works in Make, and some best practices to keep your scenarios running smoothly.

Default Error Handler

By default, if a module fails, Make pauses the scenario and marks the execution as incomplete. You’ll see a “red bubble” in the execution log.

That’s useful for debugging, but it’s not always what you want in production. Imagine:

• One failed email stops 500 others from sending.

• An API timeout causes the whole data sync to fail.

That’s where error handling paths come in.

Router Error Paths

A Router module in Make isn’t just for branching logic — it can also catch errors.

• Add a Router after a module that might fail.

• One branch continues as normal.

• Another branch is marked as an error handler.

Example:

• If an API call to Salesforce fails, route it to Slack to send a quick alert instead of breaking the whole flow.

• The rest of your scenario keeps running.

Pro tip: You can even log failed records into Google Sheets so you can retry them later.

Error Bundles

When a module fails, it generates an error bundle — basically a packet of information that explains what went wrong.

An error bundle includes:

• Error type (e.g., “Invalid request,” “Rate limit exceeded”).

• Error message (details from the API).

• Original data that caused the failure.

You can use this bundle in your error path to:

• Build meaningful alerts.

• Save bad data for analysis.

• Automatically retry only certain errors (like timeouts).

Best Practices for Error Handling in Make

1. Always test with real data. Dummy tests often pass, but real-life edge cases cause errors.

2. Separate “critical” and “non-critical” steps. If sending a Slack alert fails, that shouldn’t break your main process.

3. Log failures for visibility. Keep a lightweight “error log” sheet or database table.

4. Plan for retries. Some errors (like temporary network issues) deserve an automated retry rather than a hard fail.

5. Watch your operation count. Poor error handling can waste operations if retries loop too aggressively.

Wrapping Up

Error handling in Make is about resilience. Instead of letting one bad record bring everything down, you can design your scenarios to gracefully catch, log, and move past errors.

The next time you build, ask yourself: What happens if this step fails? Add an error path, and your scenario will thank you later.