Loading tutorials…
Loading tutorials…
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Who this is forOwners running Make scenarios in production whose failures affect real customers or data. If a broken scenario means lost orders or missed leads, you need error handlers.
What you'll need
Step 1
For each module, decide what should happen if it errors. Resume continues with next bundle; Ignore skips silently; Rollback undoes prior modules; Commit saves partial progress.
Resume: most common. If this module errors, skip THIS bundle but continue processing other bundles. Use for batch processing.
Ignore: this module is optional. If it errors, silently move on with the bundle to the next module. Use for nice-to-have enrichment that should not block the main flow.
Rollback: if this module errors, undo all prior modules for this bundle. Use for transactional flows (create order → charge card → if card fails, delete order).
Commit: explicitly save partial progress before the next module that could fail. Use when partial completion is still valuable.
Pick per-module based on what failure should mean for that step.
Step 2
Right-click a module → Add error handler → choose Resume, Ignore, Rollback, Break, or Commit.
Right-click any module → "Add error handler."
A small branch appears below the module with options: Resume, Ignore, Rollback, Break, Commit.
Pick the appropriate handler. A new path appears on the canvas — this is where you can add modules that run ONLY when this module errors.
On the error route, add modules: log to a sheet, send a Slack notification, set a flag in a data store, etc.
The error route ends naturally — bundles that go down this route do NOT continue to the original module's downstream.
Save and test by intentionally triggering a failure (disconnect a connection, malform a value).
Step 3
On the error route, add a Slack message module. Include scenario name, bundle data, error message.
On any error route, add a Slack "Create Message" module.
Configure channel: a dedicated #automation-errors channel.
Message body: include the scenario name, the module that errored, the error message, and any relevant bundle context.
Template: ":rotating_light: Scenario [name] errored at module [name]. Error: [error_message]. Bundle ID: [bundle_id]. Investigate at: [scenario_url]"
Use Make formulas to pull error details: {{1.error.message}}, {{1.error.code}}, etc.
Test by triggering an error. Verify Slack message arrives within 30 seconds.
Step 4
Wrap unreliable API modules with a retry pattern: try → if error → wait → retry → if error again → fail.
For APIs known to be flaky (some third-party services, rate-limited endpoints), implement retries.
Native Make: open the module → Settings → "Allow autoretry" → set max retries (3-5) and interval (30-60s).
Manual retry pattern: module → error handler "Resume" → Sleep 30s → re-add the module → error handler "Resume" → Sleep 60s → re-add → final error handler with notification.
Native autoretry is simpler. Manual retry gives you more control over backoff timing.
Test by temporarily lowering API rate limits and confirming retries fire then succeed.
Step 5
On error route, write the bundle data to a Data Store. Later, you can replay these failed bundles after fixing the issue.
Create a Data Store called "Failed Bundles" with columns: scenario_name, bundle_data (JSON), error_message, timestamp, replayed (bool).
On every scenario's error route, add a Data Store "Add a record" module. Write the failing bundle plus context.
Build a separate "replay" scenario that reads unreplayed records from this Data Store and re-runs them through the original logic.
Mark records as "replayed=true" after successful replay.
This is the production-grade pattern for recoverable failures. Most DIY scenarios lack this and lose data permanently on errors.
Step 6
Scenario Settings → Advanced. Set "Allow Storing of Incomplete Executions" and adjust default error behavior.
Open Scenario Settings (gear icon, bottom-left).
Under "Advanced Settings," enable "Allow Storing of Incomplete Executions." This saves errored runs so you can inspect them later in History.
Set "Default Error Handling" for the scenario: Resume (skip failed bundle, continue) is the most common production setting.
Set max execution time to a reasonable bound (10-15 min) so a stuck module does not run for 40 minutes.
Save. These settings apply to ALL modules in the scenario unless overridden by module-specific handlers.
Step 7
Intentionally cause failures (bad data, disconnected connections, expired tokens) and verify handlers fire correctly.
Test 1: malformed input. Send a bundle with invalid email format to a module that requires email. Verify the error route fires AND Slack notifies AND the bundle is logged to Failed Bundles.
Test 2: connection failure. Temporarily disconnect a connection mid-scenario. Verify the handler fires.
Test 3: rate limit. Send a burst of bundles that exceed an API rate limit. Verify autoretry kicks in and eventually succeeds.
Test 4: data store replay. Manually trigger a replay of failed bundles. Verify they re-process successfully.
If any test fails, fix the handler. Move to production only when all 4 tests pass.
Common mistakes
No error handler at all
What goes wrong: Module errors → entire scenario stops → no further bundles processed → you discover days later via customer complaint. Lost data, lost revenue, lost trust.
How to avoid: Every production scenario needs error handlers on its critical modules. At minimum: a notification handler that alerts you when ANY module fails.
Using Break when Resume was intended
What goes wrong: First bundle errors, entire scenario halts. Bundles 2-50 are never processed. 50 customers affected when only 1 should have been.
How to avoid: For batch processing, use Resume (continue with next bundle) NOT Break (halt entire scenario). Break is for catastrophic errors only.
Not logging error details
What goes wrong: You get a Slack notification 'Scenario X errored' with no context. You spend 20 minutes per error digging through History to find what failed. Errors pile up.
How to avoid: Always include in error notifications: scenario name, module name, error message, bundle ID, and a link to the scenario history. Makes triage seconds instead of minutes.
Skipping the Data Store replay pattern
What goes wrong: When errors happen, the failing bundles are gone forever. After fixing the bug, you cannot recover the data. Lost orders, lost leads, lost work.
How to avoid: Add a "Failed Bundles" Data Store. Every error route writes to it. Build a replay scenario to re-process after fixes. Production-grade recovery.
Not testing error handlers
What goes wrong: Handlers exist but you never tested them. When a real failure happens, the handler itself errors silently. Worst of both worlds.
How to avoid: Intentionally trigger each error path in testing. Verify handlers fire. Verify notifications arrive. Verify the data is logged correctly.
Recap
Done — what's next
How to use Routers and Filters in Make.com
Read the next tutorial
Hand it off
Error handling is the difference between a demo scenario and a production scenario. A specialist will retrofit handlers across your entire automation stack, set up replay infrastructure, and harden against silent failures. From $14-16/hr — most error-handling retrofit projects land at $400-1,000.
See specialist rates
Resume: bundle fails at this module, skip this bundle entirely, move to the next bundle. Ignore: bundle continues to downstream modules as if this one succeeded (useful for optional enrichment).
Yes — each retry attempt is a full module execution. 3 retries = 3 ops. Worth it for unreliable APIs, but factor into operations budgets.
Transactional flows where partial completion is worse than no completion. Example: create order → charge card → if card fails, delete order. Rollback undoes prior modules for the failed bundle.
No, one per module. You can chain logic on the error route (notify → log → store) but only one handler type per module (Resume, Ignore, Rollback, Break, or Commit).
Slack notification on Resume. Right-click critical modules → Add error handler → Resume → add Slack module. Now any failure pings you instantly. Takes 5 minutes per module and prevents silent failures.
Make
Routers and filters are how scenarios stop being linear toy automations and start handling real-world conditionality. This is the structure that prevents 1,000-line debug sessions.
Make
Iterators and aggregators are how scenarios handle arrays — looping through records, batching API calls, building emails from lists. Get these wrong and one scenario can burn your entire monthly operations budget.
Make
Data Stores are Make's built-in persistent storage. Scenarios are stateless by default; Data Stores give you memory across runs. This is the difference between toy automation and production infrastructure.
Make
Your scenario was working. Now it is failing. The diagnosis sequence specialists run is rarely random — there is a clear order that finds the root cause faster.