The Make.com Error Handling Playbook: Retries, Rollbacks and No Silent Drops

• A risk map of every module in the scenario: what happens if it fails
• Incomplete executions enabled with sensible settings
• The right error handler on each risky module
• Rate limit and outage handling that slows down instead of breaking
• Alerts that tell a person what failed and which record is affected
• A test routine that forces each failure before customers do

Octacer note: A large share of the "Make stopped working" rescues we take on come down to two settings: incomplete executions were off, and the scenario was deactivated after an error on an instant trigger. Fix those first, then refine.

Before adding handlers, know what Make does without them:

• When a module errors and there is no handler, the run stops.
• For scheduled scenarios, the Errors before deactivation setting decides how many consecutive errors Make accepts before switching the scenario off.
• For scenarios with an instant trigger (such as a webhook), Make ignores that setting and deactivates the scenario after the first error, with some exceptions listed in Make's error handling overview (Make, Scenario settings).
• For ConnectionError and RateLimitError on scheduled scenarios without incomplete executions, Make pauses scheduling for 20 minutes and does not rerun the failed data (Fix connection errors; Fix rate limit errors).

That last point is the silent data loss most teams do not know about.

1. Edit access to the scenario and its connections in Make.
2. A list of the apps the scenario touches and their API rate limits.
3. A channel for alerts (Slack, email, or a ticket queue) with an owner.
4. A safe way to test: a copy of the scenario or test records.

List every module and answer one question: if this module fails for one bundle, what is the damage?

This table becomes your build spec for the rest of the playbook.

Open Scenario settings and enable Store incomplete executions (Make, Incomplete executions). When a run fails, Make saves it with the error, the data, and the remaining flow so it can be retried automatically or resolved by hand.

Review the related settings at the same time (Scenario settings):

• Process data in order: each run finishes before the next starts, and new runs wait while incomplete executions are pending. Turn it on when order matters, such as status updates to the same record.
• Discard data if storage is full: if enabled, Make drops failed data when the incomplete executions folder is full. Leave it off for "must not lose" scenarios, and watch your storage.
• Errors before deactivation: for scheduled scenarios, set this deliberately rather than leaving the default.
• Keep data confidential: stops Make storing payloads in logs. Use it for sensitive data, knowing it makes debugging much harder.

With incomplete executions on, Make automatically retries RateLimitError, ConnectionError, and ModuleTimeoutError on a backoff schedule: 1 minute, then 10, 10, 30, 30, 30 minutes, then 3 hours and 3 hours, eight attempts in total (Automatic retry of incomplete executions; Exponential backoff). If all attempts fail, the execution stays for you to resolve.

Make has five error handlers (Make, Error handlers). Right-click a module and choose Add error handler.

Retry: for errors you expect to clear

The Retry handler pulls the failed bundle out, stores it as an incomplete execution, and lets the rest of the scenario continue. With automatic completion enabled, the defaults are 3 attempts with a 15-minute delay, and you can change both.

Use it for: a CRM that sometimes returns a 500, a record that is not yet available because another system is still writing it, a temporary validation failure upstream.

You do not need it for ConnectionError and RateLimitError. Make retries those automatically once incomplete executions are on.

Resume: for errors with a safe substitute

The Resume handler replaces the failed module's output with values you define, and the bundle continues. Use a value that is clearly a placeholder, such as NEEDS_REVIEW, and route those records to a review list so they do not quietly reach customers.

Skip: for bundles you can lose

The Skip handler drops the failed bundle, continues with the next one, and marks the run as a success even though there was an error. That last part matters: your run history will look clean. Only use Skip where losing data is acceptable, and add a log step so you can count how often it happens.

Commit and Rollback: for transaction-capable modules

Commit stops the run and keeps changes already made. Rollback stops the run and reverts changes. Both only affect modules that support transactions, marked with the ACID label, such as Data store and MySQL. Make cannot undo actions like sending an email or deleting a file in another app.

Check Commit after each module in scenario settings before relying on Rollback. When it is enabled, only the module that failed can revert, because earlier modules have already committed. When disabled, all transaction-capable changes in the bundle can be reverted.

Practical rule: put irreversible external actions (emails, payments, messages) as late in the scenario as you can, after all the writes that might fail.

Many real failures are not errors at all. A search returns no results, and the scenario carries on with empty values. Make has no native "throw" module, so you need a pattern (Make, Throw):

1. Add a filter right after the search that only passes bundles with a result.
2. Send the "no result" path to a router branch that logs the record and alerts.
3. If you want Make to retry later, Make's documentation describes forcing an error (for example with an HTTP or Parse JSON module configured to fail) and attaching a Retry handler to it.

The aim is that an empty result never becomes a blank field written into your CRM. Our CRM field that went blank playbook shows the damage this causes.

A RateLimitError corresponds to HTTP 429 Too Many Requests (Fix rate limit errors). It is common with webhook-triggered scenarios, bulk processing, and apps used in several scenarios at once.

Ways to reduce it:

• Instant scenarios: set a scenario rate limit so bursts are spread over time.
• Scheduled scenarios: reduce the number of records per run or run more often with smaller batches.
• Use bulk or search endpoints instead of one call per record where the app supports it.
• Add a Sleep module inside iterator loops that hit strict APIs.
• Spread scenarios that share an app's limit across different times.

A handled error is still an error someone may need to act on. For each "must not lose" module:

1. Add an alert on the error route or at the end of the retry path with: scenario name, module, error message, record ID, and a link to the scenario.
2. Send it to a channel with a named owner, not a shared inbox nobody reads.
3. Review the Incomplete executions tab on a schedule, for example every morning.

We explain why every sync step should post its own alert in Make the failure loud, and the no silent drops workflow playbook shows a full pattern.

Do not wait for production to test error handling. For each handler:

Make's own examples force a BundleValidationError by mapping an empty value into a required field. That is a quick, safe way to trigger handlers in a test copy.

• [ ] Risk map completed for every module
• [ ] Store incomplete executions enabled
• [ ] Process data in order set deliberately
• [ ] Discard data if storage is full reviewed
• [ ] Errors before deactivation set for scheduled scenarios
• [ ] Retry on recoverable "must not lose" modules
• [ ] Resume placeholders routed to a review list
• [ ] Skip only where data loss is acceptable, with logging
• [ ] Rollback or Commit only on ACID modules, with Commit after each module checked
• [ ] Irreversible actions placed after risky writes
• [ ] Empty search results filtered and alerted
• [ ] Rate limits handled
• [ ] Alerts include record IDs and go to a named owner
• [ ] Every handler tested by forcing the failure

• Leaving incomplete executions off. Transient errors then mean lost data.
• Using Skip everywhere. The scenario looks healthy while records disappear.
• Expecting Rollback to undo an email. It only reverts transaction-capable modules.
• Ignoring instant trigger deactivation. A single error can switch off a webhook scenario.
• Alerts without record IDs. Someone gets pinged and still cannot fix anything.

How do I make Make.com retry a failed module?

Enable Store incomplete executions in scenario settings. Make then retries connection, rate limit, and timeout errors automatically with exponential backoff. For other errors, add a Retry error handler to the module and enable automatic completion.

What is the difference between Skip and Resume in Make?

Skip drops the failed bundle and continues with the next one. Resume keeps the bundle and continues with substitute values you define.

Why did my Make scenario turn off by itself?

Usually because it reached the Errors before deactivation limit on a scheduled scenario, or because a scenario with an instant trigger hit an error. Add error handling and enable incomplete executions so errors are captured instead of deactivating the scenario.

Can Make roll back changes in my CRM?

Only for modules that support transactions, marked with the ACID label, such as Data store and MySQL. Changes made through most third-party app APIs, including CRMs, cannot be rolled back by Make. Design compensating steps instead.

How long does Make keep retrying?

For automatically retried errors, Make attempts up to eight retries over roughly eight hours on its backoff schedule. For the Retry handler, the defaults are 3 attempts every 15 minutes, which you can change.

Do incomplete executions cost extra?

They count toward your plan's storage, and retried runs use operations. Check your plan's limits in Make.

We audit and repair Make.com scenarios that drop data, switch themselves off, or double-post. Typical work:

• An error handling audit of your critical scenarios using this playbook
• Rebuilding fragile scenarios with proper handlers, alerts, and tests
• Moving heavy or high-volume scenarios to n8n or code when Make is no longer the right fit

Start with System Rescue for broken scenarios, or an Automation Sprint for a fixed-scope rebuild. See also our Make automation service or book a call.

• Not sure which platform to use: n8n vs Make vs Zapier for AI Agents
• Workflow stopped firing: When the Automation Stops Firing
• Failures that look like success: Silent Integration Failure Triage

• Make Help Center, Error handlers: https://help.make.com/error-handlers
• Make Help Center, Retry error handler: https://help.make.com/retry-error-handler
• Make Help Center, Resume error handler: https://help.make.com/resume-error-handler
• Make Help Center, Skip error handler: https://help.make.com/skip-error-handler
• Make Help Center, Commit error handler: https://help.make.com/commit-error-handler
• Make Help Center, Rollback error handler: https://help.make.com/rollback-error-handler
• Make Help Center, Exponential backoff: https://help.make.com/exponential-backoff
• Make Help Center, Throw: https://help.make.com/throw
• Make Help Center, Incomplete executions: https://help.make.com/incomplete-executions
• Make Help Center, Automatic retry of incomplete executions: https://help.make.com/automatic-retry-of-incomplete-executions
• Make Help Center, Scenario settings: https://help.make.com/scenario-settings
• Make Help Center, Fix rate limit errors: https://help.make.com/fix-rate-limit-errors
• Make Help Center, Fix connection errors: https://help.make.com/fix-connection-errors