Generic error handling is a trap. A catch-all handler tells you something broke. A routed error handler tells you what broke, why, and sends it to the right place. That difference is the gap between a scenario that fails silently and one your team can actually fix fast.

This post pulls directly from lessons we documented in our field report on using AI to build Make automations — specifically the routed error handling and self-diagnosing handler work we did with Claude. The short version: when you describe the error conditions and routing logic precisely, AI builds handlers that are specific and production-ready, not generic boilerplate.

Here is how to do it step by step.

Answer: What Does Routed Error Handling Actually Do?

Routed error handling in Make means each error condition — a failed API call, a missing field, a timeout, a rate limit — gets its own path. Instead of one generic fallback, you build specific routes that send the right data to the right place and take the right follow-up action. AI assistance speeds up the build and reduces the logic gaps that create blind spots in production.

Before You Start

Before you open Claude or your Make scenario, make sure you have these things in place:

• A working Make scenario that you want to add error handling to — or a new scenario where error handling is part of the original build
• A list of the modules most likely to fail — HTTP modules, third-party API calls, and data transformation steps are the common culprits
• A clear idea of where errors should go — email, Slack, a Google Sheet log, or a combination
• Access to the API documentation for any external tools in the scenario (you will need this if any modules use generic HTTP calls)
• Claude or another AI assistant with context on your Make scenario structure — ideally seeded with an existing scenario JSON so it understands your setup

If you are working with an MCP server connected to Make, you are in a stronger position. The MCP can read your live scenario structure and propose handler logic based on what is actually there, not a description of it.

Step 1: Define Your Error Conditions Before You Write a Prompt

This is the step most people skip, and it is the reason their error handlers end up generic. Before you ask AI to build anything, write out the specific failure modes you need to handle.

Work through each module in your scenario and ask: what can go wrong here? Common categories include:

• API errors — 400, 401, 403, 404, 429, 500 status codes. Each one means something different and warrants a different response.
• Missing or malformed data — a required field comes back null, a date arrives in the wrong format, a webhook payload is missing a key.
• Timeouts and connectivity issues — the external service does not respond within the window Make allows.
• Business logic failures — the data is technically valid but does not meet a condition your scenario requires. A record that should exist does not, or a value falls outside an acceptable range.

Write this list in plain language. You will use it directly in your prompt. The more specific your list, the more specific the handler Claude builds.

Step 2: Describe the Routing Logic to Claude in Plain Language

Once you have your error conditions listed, describe the routing logic for each one. Do not just say “handle errors.” Say what you want to happen for each condition.

A well-formed prompt looks like this:

“I have an HTTP module calling the [Tool] API. I need error handling that routes as follows: a 429 rate limit error should pause and retry after 60 seconds, up to 3 attempts. A 401 should stop the scenario and send an email alert with the scenario name and timestamp. A 500 should log the error to a Google Sheet and notify via Slack. Any other error should log to the same sheet and send an email. Build the error handler routes for this module.”

That is the level of specificity that produces usable output. Vague input — “add error handling to my scenario” — produces a generic handler that catches everything and does nothing useful with it.

If you have an MCP server seeded with your scenario JSON, Claude can reference the actual module structure and build the handler to match. This eliminates a round of manual cleanup where you have to reconnect modules or fix field mappings.

Step 3: Review the Handler Logic Before You Implement It

AI builds what you describe. It does not know your business rules unless you state them. Before you drop the generated handler into your scenario, review it against the list you made in Step 1.

Check for these specifically:

• Are all the error conditions you listed covered? Not just the ones Claude inferred, but every one you wrote down.
• Are the retry settings appropriate for each condition? A rate limit retry is different from a transient connectivity retry.
• Are the notification payloads complete? The alert should include scenario name, module name, error message, and timestamp at minimum. If it is missing any of those, go back and add them to the prompt.
• Are the routes actually separate, or did it collapse multiple conditions into one branch? Collapse is the most common shortcut AI takes when the input conditions are not distinct enough.

This review pass takes five to ten minutes. Skipping it is where AI-built scenarios develop the gaps that only show up under real load.

Step 4: Test Each Failure Path Deliberately

Testing error handlers is not the same as running your scenario and hoping something breaks. You need to trigger each failure condition on purpose.

Methods that work in Make:

• Force a 401 by temporarily removing the API key from the connection.
• Force a missing field by editing the test payload to omit a required value.
• Force a timeout by pointing the HTTP module at a URL that does not respond.
• Force a 500 by sending a malformed request body to an endpoint that returns 500 on bad input.

Run each test and verify: did the right route fire? Did the notification arrive? Does the log entry contain the fields you specified? If any of those fail, go back to Step 2 and refine the prompt for that condition. Do not patch the handler manually if AI built it — regenerate the affected route with a corrected description. That keeps your logic traceable.

Step 5: Set Up Email and Slack Notifications With Enough Context to Act On

Error notifications are only useful if the person receiving them can do something without opening Make to investigate. Build your notification payloads with that standard in mind.

Every error notification should include:

• Scenario name
• Module name where the error occurred
• Error type and status code (if applicable)
• Timestamp
• The specific data that triggered the error — the record ID, the contact name, the payload value — so the recipient knows what to check
• A suggested next step, if the error type is predictable enough to include one

That last item is where a self-diagnosing error handler takes this further. Instead of just logging the error, the handler reads the scenario structure, identifies what broke, and includes analysis and a suggested fix in the notification. We built this with our MCP server — the full build walkthrough is here. Research time per error dropped from 20 to 30 minutes down to a glance at an email. Human-in-the-loop, but the investigation work is eliminated.

For standard routed handlers without MCP integration, you can get close by having Claude draft the notification template for each error condition. Include the error context fields as dynamic variables. It builds those correctly when you describe the fields explicitly.

How to Know It Worked

Your routed error handler is working when:

• Each test failure you triggered in Step 4 produced the exact notification or log entry you specified — no more, no less
• Notifications arrive with enough context that the recipient knows what broke and what to do without opening Make
• The scenario continues or stops correctly based on the error type — retries fire on transient errors, hard stops fire on authentication failures
• No errors fall into a catch-all route that you did not intend as a catch-all

If errors are landing in your catch-all more than once, that is a signal you missed an error condition in Step 1. Go back and define it.

What Are the Common Mistakes With Routed Error Handling in Make?

Building one handler for the whole scenario instead of per-module handlers. Different modules have different failure modes. A single scenario-level handler forces you to write logic that covers every module, which produces a tangled mess. Build handlers at the module level and keep the logic clean.

Describing the outcome you want instead of the error condition that triggers it. “Send me an email when something goes wrong” is an outcome description. “Send an email when the HTTP module returns a 401” is an error condition description. Claude builds from conditions, not outcomes. Define the conditions.

Not testing failure paths before going live. Handlers that look correct in the scenario builder often have silent gaps that only appear when a specific error type fires. Deliberate failure testing in Step 4 is what catches those before they cost you.

Skipping the notification context fields. An alert that says “error in scenario” is noise. An alert that says “HTTP module failed with 429 on Contact ID 84721 at 14:32 UTC — retry in 60 seconds” is actionable. Build the context in from the start.

For a deeper look at how AI-assisted error handling connects to a full self-diagnosing system, see how this reduced technician research time in production.

Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.

Related Reading

• What months of daily AI-assisted Make builds actually taught us
• How to build a self-diagnosing error handler with an MCP server
• Seven things an AI-built Make scenario gets wrong
• How a routed AI error handler cut technician research time from 30 minutes to a glance

Sources & Further Reading

• How to Handle Errors — Make Help Center
• Overview of Error Handling — Make Help Center
• Scenarios Documentation — Make Help Center
• What Is AI Automation — Make.com
• Introducing Make AI Agents — Make.com