Make.com Error Handling: Build Resilient Scenarios That Never Break

Production Make.com scenarios fail silently—a transient API timeout at 2 AM stops your entire data pipeline and you only notice at 9 AM when someone asks why the CRM is stale. Every scenario without proper error handling is one network blip away from permanent data loss.

This guide covers every error handling primitive Make.com provides: error routes, the five error directives, retry configuration, incomplete executions, and defensive patterns for building automation that survives real-world failures.

Contains affiliate links. Disclosure.

Why most Make.com scenarios are one error away from failure

By default, when any module in a Make.com scenario throws an error, the entire execution stops immediately. Bundles that were mid-processing are dropped. No retry. No notification. No partial recovery.

This default behavior is fine for prototypes. For production automation — CRM sync, invoice processing, data pipelines — it's a silent killer. The three most common failure modes:

1. Transient API failures: A third-party API returns 503 for 30 seconds due to a deploy. Your scenario stops permanently.
2. Data shape mismatches: An upstream webhook sends an unexpected field name. Every subsequent module fails.
3. Rate limit errors: You hit a 429 from Slack or HubSpot. Make stops the run and moves on without retrying.

Make.com gives you fine-grained control over all of these — but only if you know where to look.

The error route: your first line of defense

An error route is a parallel path that activates only when a module fails. You add one by right-clicking any module → "Add error handler". This creates a new connector labeled with a red X.

The error route receives the same bundle the module was processing, plus an error object with type, message, and subtype fields you can inspect with filters.

Error routes let you:

• Log failures to a Google Sheet or Airtable
• Send a Slack alert with the exact error message
• Write the failed bundle to a recovery queue for manual review
• Attempt an alternative fallback action (e.g., switch to a backup API endpoint)

Without an error route, Make executes the default behavior for that module's error directive — which by default is Rollback.

The five error directives

Every module in Make.com has an error directive setting that controls what happens when that module fails and no error route is configured. Right-click a module → "Set up error handling" to configure it.

Directive	Behavior	When to use
Rollback	Stops the execution and marks it as failed. Rolls back any committed operations.	Default for most modules. Use when partial execution is worse than no execution.
Commit	Stops the execution but marks it as successful. Does not roll back completed operations.	Use when previous modules produced data you want to keep, even though a later step failed.
Resume	Ignores the error and continues execution with the next module, passing an empty bundle for the failed step.	Use for optional enrichment steps where missing data is acceptable.
Ignore	Same as Resume — ignores the error, passes null for the module's output, continues execution.	Use for non-critical lookups (e.g., enriching a contact with LinkedIn data that sometimes isn't available).
Break	Suspends the scenario and moves the failed bundle to the incomplete executions queue for later retry.	Use for transient failures (rate limits, timeouts) where you want to retry without losing the bundle.

The difference between Rollback and Commit matters most for multi-step workflows. If your scenario creates a Stripe payment, then sends a confirmation email, and the email fails — Rollback will attempt to void the Stripe charge. Commit keeps the charge and accepts the email failure.

Configuring a directive

1. Right-click the module
2. Select "Set up error handling"
3. Choose the directive from the dropdown
4. For Break, configure retry behavior (see next section)

Retry with Break: handling transient failures

Break is the most useful directive for production scenarios. When a module's directive is set to Break, a failed execution is sent to the Incomplete Executions queue rather than discarded. From there, Make can automatically retry it.

Configuring retry on Break

When you select the Break directive, two retry options appear:

Retry attempt limit: Maximum number of automatic retries (1–10).
Interval between retries: How many minutes to wait between attempts.

Make uses a fixed interval, not exponential backoff. If you're hitting rate limits, set a longer interval (5–15 minutes) and a retry limit that covers the typical recovery window for that service.

The incomplete executions queue

Every execution that hits a Break directive lands in Monitoring → Incomplete Executions. Each entry shows:

• The scenario name and execution ID
• The exact module that failed
• The full error message
• The bundle data that was being processed
• Current retry count and next scheduled retry

You can manually retry, edit the bundle data before retrying, or delete the execution. This queue is your recovery mechanism for any transient failure.

Important: Incomplete executions are kept for a limited time depending on your Make.com plan. On Free plans, they expire after 30 days. On paid plans, the retention window is longer. Check your plan's limits at make.com/en/pricing.

Rollback vs. commit: data consistency in multi-step scenarios

Make.com supports transactional operations in scenarios that use modules with transaction support (primarily databases and some CRM integrations). The behavior of rollback vs. commit only applies to these transactional modules.

With Rollback (default): If a scenario processes bundle A through modules 1–5, and module 3 succeeds but module 5 fails, rollback attempts to undo module 3's write operation. Not all modules support true rollback — for HTTP requests and most API calls, Make marks the execution as failed but cannot undo already-sent API calls.

With Commit: Make treats a partial execution as complete, persisting all writes up to the point of failure. The execution appears as succeeded in your history.

For most no-code automation (API calls, SaaS integrations), rollback does not truly undo external API calls — it just determines how Make reports the execution status. Reserve Commit for scenarios where you explicitly want to keep partial results.

Building a complete error handling scenario

Here's a pattern that covers the three most common production failure modes: transient errors, data errors, and critical notifications.

Scenario: CRM contact sync with full error coverage

[Webhook Trigger]
    ↓
[Validate Data] → [Error Route: Log to Sheet + Stop]
    ↓
[HTTP: Create HubSpot Contact] (directive: Break, retry 3x, interval 5min)
    ↓ error route
    [Slack: Alert on persistent failure]
    ↓
[HTTP: Send Welcome Email] (directive: Ignore)
    ↓
[Google Sheets: Log Success]

Step 1 — Validate data early: Use a filter or a Tools module to check required fields before hitting any external APIs. If validation fails, use an error route that logs the raw webhook payload and stops immediately with Commit (the validation log is worth keeping).

Step 2 — Break on transient APIs: Set Break with retry on your most failure-prone API calls (HubSpot, Salesforce, Stripe). This sends failures to the incomplete executions queue automatically.

Step 3 — Error route on Break: After retries are exhausted, the error route fires. Send a Slack message with {{error.message}} and the original bundle's key fields so you can investigate without digging through logs.

Step 4 — Ignore non-critical steps: Optional enrichment (fetching LinkedIn profile, adding tags) should use Ignore so failures there don't kill the whole run.

Accessing error data in routes

Inside an error route, Make provides a special {{error}} object:

Variable	Value
{{error.message}}	Human-readable error description
{{error.type}}	Error category (e.g., RuntimeError, DataError)
{{error.subtype}}	Specific error code (e.g., ECONNRESET, RateLimitError)
{{error.bundle}}	The bundle being processed when the error occurred

Use {{error.subtype}} with a Router to branch your error handling: retry 429s differently from 404s, and alert on 500s immediately.

Advanced patterns

Pattern 1: Distinguish retryable from terminal errors

A Router inside an error route lets you handle different error types differently:

[Failed Module]
    ↓ error route
[Router]
    ├─ Filter: {{error.subtype}} = "RateLimitError" → [Wait + Retry via Make API]
    ├─ Filter: {{error.subtype}} = "NotFound" → [Log as acceptable miss, continue]
    └─ Default → [Slack critical alert + Airtable failure log]

Pattern 2: Dead-letter queue with Airtable

For high-value bundles you can't afford to lose, write every failure to an Airtable table with the full bundle, error details, and a "status" field set to "failed". A second Make scenario polls this table on a schedule and retries records where status = "failed" and last_attempt was more than 1 hour ago.

This gives you a persistent dead-letter queue that survives Make's incomplete execution retention limits.

Pattern 3: Validate before you write

Most data errors are preventable. Before any API write operation, use a Tools: Set Variable module to validate critical fields, then branch with a Filter that only allows the bundle through if validation passes. This prevents sending malformed data to downstream APIs and avoids triggering error recovery for avoidable mistakes.

Pattern 4: Scenario monitoring with email digest

Create a dedicated "error monitoring" scenario:

1. Schedule trigger: daily at 6 AM
2. Make API: Get incomplete executions for all scenarios
3. Filter: only executions from the last 24 hours
4. Email: send digest with execution count, scenario names, and error types

This gives you a daily health report without requiring webhook infrastructure.

Error handling checklist for production scenarios

Before marking any Make scenario as production-ready, verify:

• Every module that calls an external API has either a Break directive (with retry) or an error route
• Error routes on critical paths send Slack/email alerts with {{error.message}}
• High-value bundles have a fallback write to a persistent store (Airtable, Sheets)
• Optional/enrichment modules use Ignore so they can't kill the run
• You have tested failure handling by intentionally triggering errors in dev mode
• Incomplete executions are monitored (set a bookmark in your browser to the monitoring tab)
• Your retry interval is longer than the typical recovery window for each external service

Make.com error handling vs. n8n vs. Zapier

Feature	Make.com	n8n	Zapier
Error routes	Yes — per module	Yes — error workflow	Limited — Zapier-managed retries only
Retry configuration	Manual (limit + interval)	Manual + exponential backoff	Automatic only (no control)
Incomplete executions queue	Built-in with manual retry	Built-in	No — failed zaps require manual restart
Per-module error directives	5 directives (Rollback, Commit, Break, Resume, Ignore)	Basic error handling per node	None
Transaction rollback	Partial (transactional modules only)	None	None
Error data access in route	{{error.message}}, {{error.type}}, {{error.subtype}}	$json error object	Basic error message only

Make.com has the most granular error handling of the three for complex, multi-step workflows. n8n is the better choice if you need self-hosted deployment or true exponential backoff. Zapier is appropriate only for simple two-step automations where losing a run occasionally is acceptable.

For data pipelines that use web scraping or external data sources, pairing Make.com with Apify gives you a reliable extraction layer with its own retry infrastructure — Apify automatically retries failed Actor runs before ever notifying Make.

FAQ

Frequently Asked Questions

By default, Make.com stops the entire execution immediately and marks it as failed with a Rollback directive. Any bundles being processed are discarded. No retry is attempted unless you configure a Break directive or add an error route.

Rollback stops the execution immediately and marks it as failed. The failed bundle is discarded. Break also stops the execution but moves the failed bundle to the Incomplete Executions queue, where Make can automatically retry it based on your configured retry limit and interval.

Set the module's error directive to Break. In the directive settings, you'll see fields for 'Retry attempt limit' (1–10 retries) and 'Interval between retries' (in minutes). Make will automatically retry the failed execution on the next scheduled interval.

The Incomplete Executions queue (found under Monitoring) stores failed executions that hit a Break directive. Each entry shows the error, the bundle data, and retry status. You can manually retry, edit the bundle, or delete entries. Retention period depends on your plan — 30 days on Free, longer on paid plans.

Yes. Inside an error route, Make provides the {{error}} object with {{error.message}} (human-readable description), {{error.type}} (category), and {{error.subtype}} (specific error code). Use these in Slack alerts or Router filters to handle different error types differently.

Use Ignore for optional enrichment steps where missing data is acceptable (e.g., a LinkedIn lookup that sometimes returns nothing). Use Resume similarly — it passes a null bundle to continue execution. Use Break for API calls that might fail transiently (rate limits, timeouts) where you want automatic retry without losing the data.

Partially. Make's Rollback directive attempts to undo committed operations for modules that explicitly support transactions. For most API calls (HTTP requests, SaaS integrations), rollback cannot undo already-sent API calls — it only affects how Make reports the execution status. Commit vs. Rollback mainly determines whether partial executions are recorded as succeeded or failed.

Start building resilient Make scenarios

Error handling is the single most impactful upgrade you can make to any existing Make scenario. The time investment is small — a few minutes per module — and the payoff is automation that survives real-world failures instead of silently dropping data.

Sign up for Make.com and apply the patterns in this guide to your most critical scenarios first.

For data-intensive pipelines that feed into Make — price monitoring, lead scraping, content extraction — consider pairing Make with Apify. Apify handles the heavy extraction with its own retry and error infrastructure, so by the time data reaches Make, the hard failures are already resolved.