Good Make error handling preserves work that needs attention and gives somebody a clear recovery decision. Start by separating temporary service failures from incorrect data. Repeating an invalid request rarely fixes the underlying problem.
This guide is for an existing Make scenario. If you are choosing a platform, start with our Make versus Zapier comparison.
Table of Contents
Enable storage before depending on recovery
Incomplete executions retain an unfinished run for recovery. They are disabled by default: enable Store incomplete executions in the scenario settings. Saving a failed run and successfully completing it are separate events, so somebody still needs to monitor outstanding work.
Record the scenario’s purpose, owner and acceptable delay. A failed internal report and an unprocessed customer order deserve different responses. Give the person covering absences enough context to decide whether work should wait, be corrected or be cancelled.
Choose a response for each failure
Illustrative workflow: a maintenance company turns an approved service request into an internal job record, then sends the coordinator a notification. Keep the request number attached to the work so a reviewer can reconcile the original request with the destination record.
| Failure | Proposed response | Evidence to check |
|---|---|---|
| Destination service temporarily unavailable | Retain the failed work and retry later | The expected job record exists after recovery. |
| Required customer reference missing | Have the owner correct the input or mapping | The reference belongs to the intended customer. |
| Optional internal description unavailable | Use an agreed review label if the process permits it | The coordinator can identify and complete the missing detail. |
Before replaying work, inspect what already happened in the destination. A missing notification does not establish that job creation failed. Agree how the workflow identifies an existing job before creating another, and keep automatic customer communications out of the recovery experiment.
Understand automatic retries and the Retry handler
Make’s automatic retry rules cover stored failures caused by RateLimitError, ConnectionError and ModuleTimeoutError. Attempts follow an increasing-delay schedule. Exhausted attempts leave the execution unresolved; they do not establish that the business task is complete. Retries start at the failing module, and only three incomplete-execution retries from one scenario run in parallel.
The Retry handler offers configurable automatic completion or manual recovery. Right-click the relevant module, add an error handler and select Retry. Choose whether automatic completion is appropriate, then set attempts and intervals if enabled. It also requires incomplete-execution storage.
Do not apply automatic retries indiscriminately. In the service-request example, waiting may help an unavailable destination recover; it will not supply a missing customer reference. Name the person who investigates persistent failures rather than continually extending the retry allowance.
Repair configuration inside the failed execution
Open the scenario’s incomplete-execution list, inspect the failed entry and identify the module involved. Make’s recovery instructions distinguish retrying the original configuration from manually resolving a failure that needs changes. A retry uses the settings from the failed run. Editing the ordinary scenario alone should not be treated as repairing that stored execution.
For manual resolution, open the entry’s details, correct the relevant module settings, save and use Run once. Recovery resumes at the failed module with the original input. Check the destination result afterwards. Retrying through the list requires an active scenario; deleting an incomplete execution permanently removes it.
Use Skip, Resume and Rollback deliberately
Skip discards the failed bundle and continues with remaining bundles. Make can mark that run successful despite the error. Reserve this for work you have explicitly decided may be omitted; a green result is insufficient evidence that every service request became a job.
Resume instead supplies substitute output and lets that bundle continue. An agreed internal review label might suit the optional-description example. A fabricated customer reference would not: downstream steps could act on the wrong account. Document which substitute values are acceptable.
Rollback stops processing and can reverse changes only in modules supporting transactions. It cannot recall a sent email. Previously committed changes also cannot be undone; inspect the scenario’s commit behaviour before relying on reversal. Treat recovery across several business apps as something to verify, not a guaranteed all-or-nothing operation.
Check ordering, storage and plan limits
The scenario settings reference explains that enabling ordered processing pauses new runs until outstanding incomplete executions are resolved. That may protect ordering, but it can also hold up unrelated work. Decide whether later requests can safely proceed while one is waiting.
Storage is finite and depends on your usage allowance. Make’s storage exceptions include first-module errors unless a Retry handler is attached there. Runs exceeding their duration limit are not saved as incomplete executions either. When storage fills, the data-loss setting determines whether scheduling stops or failed data is discarded. Review that setting before an outage, not during one.
The current plan table lists a five-minute maximum scenario duration on Free and 40 minutes on paid plans. Detailed execution logs are retained for seven days on Free, 30 on Core, Pro and Teams, and 60 on Enterprise. Consider investigation time as well as credit allowances before upgrading.
Check recovery before handing it over
- Use harmless sample records. Define the expected job and notification for each request.
- Challenge the required data. Confirm that a missing reference reaches a named reviewer.
- Inspect partial completion. Check for an existing job before attempting recovery.
- Account for every request. Compare source records with completed, waiting and deliberately cancelled work.
- Hand over the process. Ask the backup owner to find one failed entry and explain the next action.
These are proposed acceptance checks, not reported test results. For processes that lead to billing, our invoicing automation guide covers the wider business workflow.
Sources reviewed 27 September 2026 against official Make documentation. The service-request example and acceptance checks are illustrative recommendations.
