Make scenario error handling should answer more than “how do we make the run green?” A failed run may already have created a contact, sent a message, or submitted an invoice before another module failed. Repeating the whole run can repeat those business actions.
Quick answer
The safest recovery method is to locate the failed module, establish which earlier actions actually happened, and choose a bounded recovery path. Preserve uncertain cases for review. Use automatic retries only when repeating the affected action is safe and the underlying cause is genuinely retryable.
Key takeaways
- Check which business actions happened before the module failed.
- Choose a handler for its business effect, not just a green execution status.
- Retry only safely repeatable actions within a bounded recovery and escalation plan.
Documentation reviewed October 9, 2026. The examples are fictional workflow designs, not tested performance claims. Validate settings in your own scenario and connected applications.
Draw the business actions before choosing a handler
Write the scenario as a short chain of real outcomes: receive request, validate fields, create record, notify owner, record completion. Next to each outcome, note whether it reads information or changes another system. The distinction matters because reading a contact twice is different from sending the same customer two confirmations.
Assign a durable reference to the business request where one exists. This might be an order reference, approved submission identifier, or another non-sensitive stable key. Do not use the scenario run time as the only identity if retries must be recognized as attempts to process the same request.
Then identify the evidence available after each action. A destination record ID, provider response, or verified lookup can help distinguish an action that succeeded from one that never happened. A timeout alone does not settle that question: the destination may need to be checked through its own supported tools.
If you are still selecting an automation platform, our Zapier versus Make comparison provides context. Here, the goal is to recover an existing Make scenario without replaying business consequences that have already occurred.
Understand incomplete executions without assuming they are enabled
Make’s incomplete-execution documentation says unfinished runs can be stored when this feature is enabled; it is disabled by default. Recovery can be manual or automatic for supported error types or through the Retry handler. Storage limits also apply. Verify the actual scenario setting rather than assuming failed work is safely queued.
Preserving a run is useful only if someone owns the recovery process. Decide who reviews unresolved items, how they determine whether an action already succeeded, and what evidence they record. An unattended queue can become a hidden backlog even while newer business requests appear to process normally.
Do not describe stored executions as a universal backup of everything in the business workflow. Keep the authoritative request and necessary recovery records in approved systems. If your incident investigation cannot establish what was retained, state that uncertainty before choosing a replay strategy.
Match the handler to the business outcome
Make’s current error-handling overview describes Skip, Retry, Resume, Commit, and Rollback. Skip removes the affected bundle; Resume supplies substitute output; Retry preserves unfinished work for recovery. Commit and Rollback have transaction-specific behavior, and rollback does not undo changes in modules that lack transaction support. A successful run status does not prove every intended business action occurred.
| Business situation | Recovery decision | Required evidence |
|---|---|---|
| Temporary read failure | Consider bounded retry | No repeated write involved |
| Invalid required input | Quarantine for correction | Original request preserved |
| Optional enrichment unavailable | Consider explicit fallback | Downstream logic accepts unknown |
| Write outcome uncertain | Verify destination first | Request key and destination lookup |
| Critical write partly complete | Recover remaining action only | Confirmed earlier side effects |
The table proposes design choices, not automatic handler assignments. A “temporary” error can still affect a write whose outcome is uncertain. A missing optional field can become critical if the next module interprets a blank value as authorization. Review the business meaning before translating a case into a handler.
Create a recovery ledger for important actions
A recovery ledger is a design pattern: a restricted record of request identity, attempted action, outcome, destination reference, and next step. It need not be a complicated new platform. The important property is that an operator can distinguish “not attempted,” “confirmed complete,” “failed,” and “outcome unknown.”
Never label an uncertain write as failed simply because Make did not receive the expected response. Verify the destination using its supported record lookup or provider evidence. Conversely, do not mark the entire business request complete when only an early module succeeded. Record completion at the level of the action you can actually verify.
Keep the ledger free of unnecessary personal information and secrets. Store references rather than full payloads where possible. Document who can read it and how long it is retained. Error notifications should direct the operator to the approved evidence, not expose customer data in a public chat channel.
Concurrency also needs a design review. Two attempts can both read “not complete” before either writes completion. A simple search-then-create sequence should not be described as guaranteed duplicate prevention. For high-impact work, ask a developer to evaluate the destination’s uniqueness or idempotency capabilities and how simultaneous attempts are controlled.
Design the error route deliberately
Keep bad input out of repeated retries
A missing required value will not usually repair itself while the same request is retried. Route it to an owned correction process with a useful explanation. Preserve the original value and the approved correction separately so an operator can understand what changed.
Do not invent a plausible phone number, customer identifier, or financial value just to satisfy a destination field. If the destination permits an explicit unknown state, evaluate that supported state with the business owner. Otherwise, pause the action until valid information is supplied.
Use fallback output only where its meaning is safe
For optional enrichment, define what downstream modules should do when information is unavailable. An explicit “unverified” classification may be safer than a guessed category. Review filters and branches so that a fallback does not silently grant access, route money, or trigger customer messaging.
Document the quality trade-off. Completing a workflow with less information can be acceptable for an internal draft summary but unacceptable for a binding transaction. The choice belongs to the business requirement, not the convenience of the error route.
Set a retry budget and an escalation owner
For a reviewed case, Make’s Retry setup instructions show the module’s Add error handler option, followed by Retry. Configure Automatically complete execution deliberately: automatic recovery uses your chosen attempts and interval; manual recovery leaves the item for review. Enable Store incomplete executions in scenario settings and save. Do not copy an example retry interval without evaluating your destination.
For a genuinely temporary problem, decide how many recovery attempts are acceptable and when a human must review it. Consult the specific connected application’s limits and the applicable Make documentation before selecting timing. Do not assume that rapid repeated attempts will solve a provider-side restriction.
After the retry budget is exhausted, preserve the request and alert the owner. Include the failing action, stable reference, first failure time, and a safe summary of the error. An alert without an owner or a clear recovery decision is just another unresolved output.
Recover a partial run step by step
In Make, open the scenario’s Incomplete executions tab, locate the item, and choose Details. Inspect the module with the warning. The recovery instructions distinguish retrying with the original configuration from manually resolving a case that needs changed settings. A supported retry starts at the failed module, not at the beginning of the entire scenario. That failed module can itself have an uncertain write outcome, so verify its destination before retrying.
First capture the failed execution and its module-level evidence. Second, inspect the destination for earlier writes. Third, classify the unfinished action as safe to repeat, unsafe to repeat, or uncertain. Fourth, correct the root cause. Finally, use the supported recovery path that performs only the necessary work.
Do not clear the incomplete item solely to tidy the queue. Record how the business request was resolved, including cases intentionally abandoned with approval. Otherwise, an apparently empty queue can conceal unprocessed orders or messages.
If you must reconstruct work outside the original execution, have the operator record the replacement action and destination reference. Ensure the original case will not later be recovered automatically and repeat the replacement. Coordinate with the scenario owner before making this kind of manual intervention.
For recurring operational tasks, our recurring-task automation guide helps clarify ownership. Reliability is not just a module configuration: someone needs to be accountable for exceptions, backlog review, and changes to the connected systems.
A fictional case: contact created, notification failed
Consider a scenario that receives an approved enquiry, creates a CRM contact, and posts an internal notification. The notification module fails. Replaying the whole process without checking the CRM may create another contact, even though the only unfinished business action is notifying the owner.
The recovery record should retain the enquiry reference and the verified CRM contact ID. The operator checks whether the notification was delivered before repeating it. If the evidence confirms that it was not delivered, the recovery path sends the missing notification while preserving the existing contact.
If the notification outcome is uncertain, a second message should not automatically be treated as harmless. It could trigger two follow-up calls. The team can design the notification to include a stable request reference and a clear recovery label, but should still agree on how duplicate operational responses are prevented.
This example shows why the point of failure and the point of recovery are not interchangeable. The workflow needs a business-level completion definition. It is complete when the intended contact and follow-up responsibility exist, not merely when a rerun has a favorable status.
Test failure paths as carefully as the happy path
Use isolated fixtures and approved test destinations where possible. Deliberately exercise a missing required field, an unavailable optional service, and a failure after a confirmed write. Do not induce outages, exhaust quotas, or send unwanted messages in production to prove that a handler runs.
For each fixture, define the expected business outcome before running it. Check the destination records, unresolved queue, recovery ledger, and operator notification. Include a repeated request and a simultaneous-attempt case if your workflow can receive either. Ask a developer to review concurrency behavior when the stakes justify it.
Retain screenshots or sanitized logs showing the relevant outcome. Confirm that temporary test routes and credentials are removed through the approved process. Our AI workflow automation guide is useful when generated classifications or text are part of the flow, but AI output should not be used to guess whether a transaction completed.
Questions before returning to production
Will Rollback undo a message or a remote API action?
Do not assume it will. Transaction support is module-specific. Check the documented behavior of the actual modules and verify real side effects before recovery.
Is Skip acceptable for a failed invoice?
Not just because it keeps other bundles moving. A critical omitted action needs an owned exception and a documented outcome. Decide whether it can be skipped with the responsible business owner.
Can I retry every incomplete execution together?
Only after establishing that the selected items are safe to repeat and their causes are resolved. Start with a reviewed small set rather than treating a bulk retry as a universal fix.
A safer definition of recovery
Good Make scenario error handling preserves the request, distinguishes confirmed actions from uncertain ones, and completes only the remaining work. Start by mapping side effects for one critical scenario. Then add bounded recovery, clear ownership, and failure-path tests before increasing automation volume.
Join the conversation
Share a useful perspective, question, or first-hand experience with other Daily Jade readers.