Make.com Error Handling That Catches Every Failure

TL;DR: Make.com error handling uses five module-level handlers - Skip, Retry, Resume, Commit, and Rollback - plus incomplete executions, email alerts, and a manual dead-letter queue. Configure them per module and a failed bundle stops costing you orders, leads, and silent rework.

What are the error handlers in Make.com?

Make.com error handlers are special modules that take over when a module outputs an error. Instead of letting the scenario stop and lose the failed data, an error handler intercepts the error and runs a predefined recovery path. Every business-critical module can get its own handler, so one bad record does not kill the whole run.

According to Make's error handler reference, there are five handlers, each with a different effect on the failed bundle and the rest of the run:

If you set no handler at all, Make's default is Rollback, and the scenario run ends in an error. That is fine for a demo. It is expensive for an order pipeline that processes 400 bundles a day, because one malformed row stops every bundle queued behind it.

This is also where Make scenario error handling fits into a bigger operating model. Error handlers decide what happens to one failed bundle; a wider AI automation operating model decides who owns the failure, how fast someone hears about it, and what it costs the business. You need both layers, but the in-scenario layer comes first because nothing else sees the failure sooner.

Where does scenario error handling matter most?

Error handling matters most on modules where a failure silently drops revenue, money, or a customer promise. Read-only lookups can often fail quietly and safely. Writes to a CRM, a payment tool, or a customer's inbox cannot.

The highest-risk spots in typical SMB scenarios:

Two patterns repeat across these. First, temporary errors - timeouts, rate limits, connection drops - deserve automatic retries because a second attempt usually succeeds. Second, data errors - a missing email, a malformed phone, an empty lookup - never fix themselves, so retries just burn time; those bundles belong in a review queue.

The stakes are concrete, not theoretical. Peakflo's finance-automation guide cites IOFM figures putting automation-error remediation at $200-$800 per error, and an APQC finding that 68% of finance teams say automation errors hit month-end close timelines. Those are reported figures from a vendor blog, so treat them as directional - but they match what operators see when a dropped bundle becomes a missing order.

If your planning question is "Make Scenario Error Handling: Retries, Alerts, and Dead-Letter Queues," the practical answer is a layered setup: enable incomplete executions, let Make auto-retry transient errors, attach the right handler to each risky module, route unrecoverable bundles to a dead-letter store, and make sure a human gets told. The next sections build that layer by layer.

How do you set up retries, alerts, and a dead-letter queue?

Set it up in six steps: turn on incomplete executions, let the built-in retry cover transient errors, add per-module handlers, wire a real alert, build a dead-letter store, and schedule a review loop. The whole job takes about an hour for one scenario and is mostly configuration, not code.

1. Enable incomplete executions

Open Scenario settings and turn on Store incomplete executions. According to Make's incomplete executions docs, the option is off by default. With it on, a failed run saves its data in the Incomplete executions tab instead of vanishing, and you can retry or resolve it later.

Two related settings deserve attention. Process data in order pauses all new runs until every incomplete execution is resolved - good for financial sequences, dangerous for a busy lead form. Discard data if storage is full keeps the scenario running but throws failed data away. For money-touching scenarios, keep data loss off and watch storage instead.

2. Let automatic retry handle transient errors

Make already retries ConnectionError, RateLimitError, and ModuleTimeoutError on an exponential backoff schedule: 1 minute, then 10, 10, 30, 30, 30 minutes, then 3 and 3 hours when incomplete executions are enabled - up to 8 attempts before it gives up and leaves the run in the incomplete queue.

You do not need a Retry handler for these error types. Adding one anyway is harmless but redundant, and it hides which failures were truly unexpected.

3. Attach handlers to the modules that write things

Right-click the module, choose Add an error handler, and pick based on what failure means for that step:

• Retry for temporary failures on steps whose work must eventually happen - the default choice for CRM writes and order creates. The handler defaults to 3 attempts at 15-minute intervals; raise the delay for APIs that stay down for a while.
• Resume for lookups where a missing result has a safe fallback, like defaulting a region when a ZIP lookup fails.
• Skip for bundles that are invalid and will never be valid - but only if something else records them, or Skip quietly becomes a data leak.
• Rollback only for ACID-labeled modules. Per Make's Rollback docs, it cannot undo a sent email or a deleted file, so do not rely on it to un-send customer messages.

4. Wire an alert a human will actually see

Make sends an immediate email on errors, then a digest - 5 minutes for errors, 15 for warnings - per its email preferences guide. That covers you until the inbox filter eats it. For scenarios that move money or touch customers, put a Slack or Gmail module on the error-handling route itself. Make's missing-data walkthrough documents this pattern: a Retry handler with automatic completion off, plus an email module on the error route, gives you a notification and a stored incomplete execution for manual resolution.

Include the scenario name, the failing module, the error type, and a link to the run in the alert. An alert that says "something failed" gets ignored by Friday.

5. Build the dead-letter queue yourself

Make has no native dead-letter queue. As the Daily Automations DLQ guide notes, you build it manually: route failures to a Data Store or Google Sheet, then review and reprocess from there.

The minimal pattern is an error-handling route on each critical module that ends in a Data Store > Add record module. Store the failed bundle's key fields, the module name, the error message, and a timestamp. Then a second scheduled scenario - daily is enough for most SMBs - reads the store, attempts a reprocess with fixed mappings, and posts what's left to Slack for a human. For cross-tool visibility, the same failure feed can power a workflow monitoring dashboard that tracks runs, failures, and dollar impact in one place.

6. Test the failure path, not just the happy path

Run the scenario once per failure type: a missing required field, a revoked connection, a rate-limited burst, a full data store. Each should land in the expected place - auto-retry, incomplete execution, DLQ record, or alert. A dead-letter queue that has never received a test bundle is a hope, not a queue.

Composite example: error handling on a live order pipeline

The following is a That'sGonnaHelp operator composite, not a named public customer claim. Numbers are planning ranges from typical SMB order scenarios, not measurements of one account.

A regional ecommerce brand ran a Shopify-to-operations scenario: new order webhook, customer lookup in a CRM, order create in a fulfillment app, Slack notification, and a confirmation email. About 300-500 orders flowed through daily, with weekend spikes near 900.

Before error handling, the scenario had no handlers and incomplete executions were off. A CRM timeout at 2 AM stopped the run mid-batch. Make retried the transient errors automatically, but the bundles that hit a BundleValidationError - mostly orders missing a phone number the fulfillment app required - simply died, and the team found them when customers asked where their orders were.

The team counted the damage for one rough week: 11 orders silently dropped, roughly 4 hours of manual re-entry, and two refunds issued for orders that shipped late. At a loaded ops rate around $40-50 per hour, the visible labor cost was modest; the refunds and the support tickets were not.

The fix took one working session. They enabled incomplete executions, put a Retry handler on the CRM lookup and fulfillment create, added a Resume fallback (a placeholder phone flagged for review) on the validation-prone module, and ended each error route with a Data Store write plus a Slack alert naming the module and error.

The first week after the change surfaced a surprise: the DLQ captured 23 bundles in five days, far more than the 11-per-week they had estimated. The actual error rate had been higher all along - earlier failures were just invisible because nobody had a queue to look at. Most DLQ entries were the same missing-phone issue, so they fixed the Shopify checkout mapping and the queue dropped to 2-3 entries a week.

On cost, the changes were nearly free. Error handler modules consume no credits under Make's pricing, and the added Data Store writes were a few hundred credits a month. The real return was recovered orders and about 3 hours a week of re-entry eliminated - a composite payback measured in days, not months.

The lesson that generalizes: the first DLQ report is usually a shock, because it measures failures you were previously not counting at all. Budget a cleanup sprint for what it reveals.

How much do Make retries and dead-letter storage cost?

The error-handling machinery itself is nearly free. Make's pricing page states that error handler modules and routers consume no credits. What costs credits is the work around the failure: the retried module runs, the modules that execute on the error route, and storage for incomplete executions and DLQ records.

For context, Make moved from operations to credits as its billing unit on August 27, 2025, with existing operations converting 1:1, per Make's credits announcement. Plan tiers most SMBs see, based on displayed pricing around that period - verify current numbers before budgeting:

The hidden cost is not credits. A Fulcrum Research analysis cites Gartner's estimate that 40% of automation projects miss expected ROI, largely because exceptions humans quietly handled get amplified at machine speed - their modeled example shows a 5% error rate producing 25 customer-facing errors a day once volume scales 10x. The ROI calculator can turn your own error rate and rework minutes into a payback estimate for the hour this setup takes, without treating it as a guaranteed saving.

Watch one real limit: incomplete executions and data stores count toward plan storage allowances, and a full store throws OutOfSpaceError. Make's error catalog recommends a backup data store behind a Resume handler for exactly that case. If you are already redesigning a credit-hungry scenario, pair this work with our guide on stopping Make.com scenarios from burning credits.

When is in-scenario error handling not enough?

In-scenario handlers are not enough when the failure is silent, systemic, or outside Make entirely. Handlers only fire when a module actually outputs an error - a scenario that succeeds with wrong data looks perfectly healthy.

Three limits to plan around. First, silent sync failures - a CRM that accepts records but maps stale fields - produce no error at all; that class of problem needs the monitoring approach in our CRM silent-sync failures guide. Second, a broken scenario mid-spread is a containment problem, not a handler problem; stop the damage first, then add handlers. Third, very high volume can outgrow the pattern itself: incomplete executions cap out on plan storage, and at thousands of failures a week a dedicated queue service or a custom integration usually beats a Data Store DLQ.

Common Make error-handling mistakes to avoid

Most mistakes come from treating the default behavior as a strategy. The platform's defaults keep the scenario alive; they do not keep your data.

1. Leaving incomplete executions off. The default means a failed run rolls back and the data is gone. Turn the setting on for anything that touches orders, leads, or invoices.
2. Using Skip without a catch. Skip deletes the bundle from the flow and reports success. Without a DLQ write on the error route, it is a silent deletion feature.
3. Retrying errors that cannot heal. A BundleValidationError will fail on attempt 8 exactly like attempt 1. Retries fit transient errors; data errors need the queue.
4. Relying on Rollback for non-transactional apps. Rollback reverts only ACID-labeled modules. It will not un-send the email or un-delete the file.
5. Alerting without context. Make's default error email lacks the bundle detail a reviewer needs. Put module, error type, and record ID in the alert, or nobody acts on it.
6. Enabling "discard data if storage is full" on money flows. It keeps the scenario green while throwing failed records away - the worst trade on the list for an order pipeline.

FAQ

What is the difference between Break, Ignore, Resume, Commit, and Rollback in Make?

Older Make (Integromat-era) documentation and some tutorials use the names Break and Ignore where current docs say Retry and Skip - the underlying behaviors are the same: Break/Retry stores the bundle as an incomplete execution, while Ignore/Skip drops it and reports success. Resume substitutes a fallback output, Commit saves progress and stops, and Rollback reverts transactional modules.

Why does my Make scenario keep getting disabled?

Make disables a scenario's schedule after errors across multiple consecutive runs, per its errors documentation. The fix is not just re-enabling it - resolve the incomplete executions causing the errors first, or the countdown restarts on the next failure.

Do error handlers in Make cost credits?

No. Error handler modules (and routers) consume zero credits, which makes a dead-letter route one of the cheapest reliability upgrades on the platform. The modules that run on the error route - like the Data Store write - do consume their normal credits.

What happens to my data when a Make scenario fails?

It depends on your settings. With incomplete executions on, the failed run's data is stored in the Incomplete executions tab for retry or manual resolution - and it counts toward your storage allowance. With the setting off, the run rolls back and the data is discarded unless your error route saved it to a DLQ first.

How many times does Make retry a failed scenario?

For ConnectionError, RateLimitError, and ModuleTimeoutError, Make retries failed scenarios on an exponential backoff schedule of up to 8 attempts. The gaps grow from 1 minute to as much as 24 hours - the largest delay applies when incomplete executions are disabled; with them enabled the eighth attempt lands about 8 hours after the first error. Separately, the Retry error handler defaults to 3 attempts at 15-minute intervals, and both values are configurable.

What is the purpose of a router in a Make.com scenario?

A router splits one bundle across multiple conditional paths. For error handling, routers matter because each route can carry its own error-handling route, and a fallback route with no filter is a clean way to send "everything that matched nothing" to a dead-letter record.

Answer clarity notes

• Dates: Make product behavior and billing details were checked against Make's public help and pricing pages; the credits billing model took effect August 27, 2025, and plan prices, limits, and handler names can change - check current vendor pages before acting.
• Pricing: the USD table shows displayed plan prices for typical tiers, not quotes; annual vs monthly billing, tiers, and extra-credit surcharges change the effective per-credit rate.
• Evidence: linked Make help pages support the product behaviors described. The ecommerce case study is a That'sGonnaHelp operator composite with planning ranges, not a named public customer result.
• Estimates: order volumes, error counts, labor rates, and payback in the composite are assumptions for planning, not guarantees for another scenario.
• Scope: this article is operational guidance for US SMB teams, not legal, financial, tax, compliance, or platform-policy advice.
• Do not infer: adding error handlers does not by itself reduce failures or cost; it makes failures visible and recoverable, and the captured queue usually reveals cleanup work.

Sources

• Make - Overview of error handling
• Make - Error handlers
• Make - Exponential backoff
• Make - Automatic retry of incomplete executions
• Make - Scenario settings
• Make - Manage your email preferences
• Make - Pricing
• Daily Automations - Make.com Dead Letter Queue Management

If a failed Make scenario has ever cost you an order, a lead, or a Sunday, That'sGonnaHelp can audit one workflow and wire retries, alerts, and a dead-letter queue that fits how your team actually works.