Make.com Error Handling for AI Scenarios: 5 Patterns That Don't Break at 2am

The difference between a Make.com scenario that “works on my machine” and one that runs reliably in production is error handling. AI automations fail in particular ways — rate limits, model timeouts, occasionally broken JSON — and if your scenario isn’t ready for those failures, it will break at the worst possible time.

This post covers the five error handling patterns I use in every production AI workflow. Copy-paste ready, each with the specific Make.com settings.

Why AI Scenarios Fail

Before the patterns, the failure modes you need to protect against:

1. Rate limits (429) — transient, usually fixable by retry
2. Model timeouts / 500 errors — Anthropic’s servers having a moment
3. Invalid JSON output — Claude occasionally adds preamble or malformed the JSON
4. Missing input data — upstream module returned nothing unexpectedly
5. Credit exhaustion — your API account ran out of credit
6. Network blips — transient connectivity errors

Each needs a different response. Blanket “retry 3 times” doesn’t work — retrying a credit exhaustion error 1,000 times just wastes operations.

Pattern 1: Break with Retries (for transient errors)

Use for: 429 rate limits, 500 server errors, 529 overloaded errors, network timeouts.

Setup:

1. Right-click the Claude (or any AI) module → Add error handler
2. Pick Break
3. Configure: - Number of attempts: 3 - Interval between attempts: 30 seconds - Automatically complete execution: checked

What it does: if the module errors out, Make waits 30 seconds, retries. Up to 3 attempts total. If all fail, the execution completes cleanly without breaking the scenario.

This handles 90% of transient AI errors silently. The user never knows; the work gets done on retry 2 or 3.

When to use: on every AI module. No exceptions.

Pattern 2: Resume with Default (for missing data)

Use for: upstream module returned empty/null and downstream modules can’t handle it gracefully.

Setup:

1. Right-click the module → Add error handler
2. Pick Resume
3. In Output, provide a default value for the field that would have been empty

Example: Claude module returns empty content. Downstream module expects a string. Instead of failing, Resume provides the default string “Analysis not available” and the scenario continues.

When to use: when downstream processing can meaningfully continue with a default. Don’t use this to hide bugs — use it to keep scenarios running with sensible fallbacks.

Pattern 3: Rollback with Alert (for critical failures)

Use for: failures you want to know about — credit exhausted, invalid API key, something structurally wrong.

Setup:

1. Right-click the module → Add error handler
2. Pick Rollback
3. Before the Rollback, add a Telegram or Email module that sends an alert with the error details

Example flow:

[Claude module] 
    ↓ (error)
[Telegram: "Claude API error: {{error.message}}"]
    ↓
[Rollback: stop execution, don't process partial data]

What it does: full stop on the scenario, explicit alert to you. Nothing worse than a broken automation running silently for days.

When to use: for errors that mean the scenario can’t work correctly and needs human attention.

Pattern 4: JSON Repair Fallback

Use for: when Claude returns text that should be JSON but isn’t valid.

Problem: you ask Claude for a JSON response, downstream Parse JSON fails because Claude added ```json code fences or a “Here’s the JSON:” preamble.

Setup:

1. After Parse JSON, add error handler → Break with 1 attempt
2. Route the error path to a second Claude module with this prompt:

The previous output was not valid JSON. Here is the output:

{{input}}

Return ONLY the valid JSON contained in it. Strip any markdown code fences, preamble, or explanation. Return ONLY JSON.

3. Feed that output into Parse JSON again

Why it works: Claude is great at fixing its own malformed output when explicitly asked. This turns a scenario-breaking error into a self-healing one.

When to use: any workflow where Claude’s output needs to be parsed as JSON. This pattern alone has saved me dozens of 2am debugging sessions.

Pattern 5: Circuit Breaker with Data Store

Use for: high-volume workflows that could run up a huge bill if something goes wrong.

Setup:

1. Create a Data Store called circuit_breaker with a record structure: {last_error_count: Number, last_error_time: Date}
2. At the start of each scenario execution, Get record from the Data Store
3. Filter: only continue if last_error_count < 10 or the last error was more than 30 minutes ago
4. On the error handler of your AI module: Update the Data Store to increment last_error_count

What it does: if the scenario starts erroring in a loop, the circuit breaker trips after 10 errors and stops the scenario from firing until 30 minutes have passed. You don’t come back to find you burned through $200 of credits on a broken loop.

When to use: production workflows with real cost implications. Overkill for test scenarios, essential for scaled ones.

Setting Up Error Notifications

All five patterns benefit from alerts. Two approaches:

Simple: Make.com’s built-in scenario notifications. Go to the scenario → Settings → Notifications → turn on email alerts for errors and warnings.

Better: a dedicated error-alert module on each error handler path. Examples:

• Telegram message — near-instant, I read them on phone
• Email with screenshot — works if you want a paper trail
• Slack webhook — if your team uses Slack

My default: Telegram. Quickest signal, least noise, works offline.

The Scenario Settings That Matter

Beyond module-level error handling, set these at the scenario level:

1. Data loss (Settings → Advanced): set to Rollback — means if scenario fails, no partial state gets written
2. Allow storing incomplete executions (Settings): Yes — lets you debug failures after the fact
3. Max number of executions per minute: set this. Even 60 is better than unlimited — prevents runaway loops

Logging That Helps Debugging

Add a Tools → Data store module at key points in your scenario to log:

• Input received
• Output from each AI module
• Timestamp and duration

When something goes wrong three weeks from now, this log lets you recreate exactly what happened. Make.com’s execution history shows outputs too, but they expire after 30 days.

Testing Your Error Handling

Don’t assume your error handling works — prove it. Simulate failures:

• Rate limit: temporarily lower Anthropic tier or use a key with limited credit
• Invalid JSON: tell Claude to return a response with markdown code fences
• Missing data: send an empty payload to your webhook
• Network error: hard to simulate, but Make’s Break module behaviour is well-tested

Run through each failure mode with your scenario in Run once mode. Watch the error handlers activate. Confirm they do what you expected.

The Minimum I Ship

For any production Make.com scenario with AI modules, minimum error handling is:

1. Break + 3 retries on every AI module (Pattern 1)
2. JSON repair fallback if any JSON parsing is involved (Pattern 4)
3. Telegram alert on scenario-level failures (Settings)
4. Data loss rollback in scenario settings

That’s maybe 15 minutes of setup for a scenario. Saves me from 3am phone buzzes and surprise bills. Non-negotiable.

Next Steps

The Implementation Blueprint course ($29) includes production-ready scenario templates with error handling built in, plus a walkthrough of each pattern above applied to a real-world scenario. Copy-paste ready.

---

Last updated: 20 April 2026.