Make Incomplete Executions Explained: Retry, Resolve, or Delete

What it preserves, and what it doesn’t prove

When a module fails and the scenario has incomplete execution storage enabled, Make can store the failed run’s scenario blueprint, the mapped data waiting to be processed, and the error that stopped it, so a builder can investigate and continue the run later rather than losing it. This storage is not automatic for every failure: whether an incomplete execution is created depends on the scenario’s settings, the specific error type, whether an error handler is attached, conditions on the first module, storage availability for the team, and other documented behavior. Treat “was an incomplete execution created” as a fact to check, not an assumption. The Make platform hub separates this recovery guide from concurrency and usage-counting references.

What an incomplete execution does not prove is whether the module’s external action actually completed on the connected app’s side before the error was raised. It records that Make did not receive a successful result; it does not, by itself, tell you whether the third-party system processed the request, rejected it, or never received it at all. That gap is the reason evidence review comes before any retry decision.

Status reference

Evidence checklist

Capture this before retrying or editing anything, since some of it becomes hard to reconstruct once a retry or resolution changes the record:

• Incomplete execution ID
• Error class and full error message
• Scenario version and configuration at the time of failure
• The specific module that failed
• The original mapped input to that module
• Attempt count so far
• Timestamps for the original failure and any subsequent attempts
• Which preceding steps in that run already completed successfully
• Any external record or request ID the failing module’s target system may have generated
• Whether an automatic retry is currently pending for this execution

Decision matrix

Automatic retry and backoff

Under documentation verified on 9 August 2026, automatic retry of incomplete executions applies to incomplete executions created by RateLimitError, ConnectionError, and ModuleTimeoutError, as well as incomplete executions created through a Retry error handler with automatic run completion enabled. Other error types are not automatically retried by default and generally require manual resolution instead.

Automatic retries are scheduled on an exponential backoff pattern rather than fixed, evenly-spaced intervals, so consecutive attempts get progressively further apart. This spacing exists specifically to avoid immediately repeating the same failure against a service that is still unavailable, giving a later attempt a better chance of landing after the underlying condition clears. Avoid publishing exact minute-by-minute intervals as a fixed table; the interval pattern is subject to change, and a dated qualitative description is more durable than numbers that can drift out of sync with the platform.

Under current documentation, each scenario is limited to three incomplete execution retries running in parallel; additional incomplete executions from the same scenario are retried in batches after the prior batch finishes, and a scenario’s incomplete-execution retry does not start while that scenario’s own execution is already running. State this as documentation verified on 9 August 2026, not as a permanent platform ceiling, since these limits can change.

What resumes, and why uncertainty remains

A retry restarts processing at the module that caused the error, using the same module configuration that was in place when the failure happened; it does not restart the scenario from its first module. This matters for both correctness and cost: modules that already completed successfully before the failure are not re-run by a retry, so a retry does not by itself repeat their downstream effects.

The genuine uncertainty sits specifically at the failing module. Because a timeout or a connection error can occur very close to the moment an external action actually takes effect, Make’s error alone cannot tell you whether that action completed before the error was raised. This is not a claim that retrying always duplicates the earlier action, and it is not a claim that retrying is always safe either; Make’s documentation describes the incomplete execution as resuming from the failing module, and the specific uncertainty is whether the target service completed that module’s action before Make received the error or timeout. Where that uncertainty matters, checking the target service’s own record, or using a stable idempotency or business key in the module’s request, is an operational design recommendation, not a guarantee Make itself provides. Make does not document atomic rollback of ordinary, non-transactional actions in third-party apps; where a Rollback-style mechanism is documented, it applies only to the depth Make’s own error-handling documentation supports, not as a general undo for any connected app’s action.

Relationship with Process data in order

When Process data in order is enabled and an incomplete execution exists for that scenario, Make postpones new scheduled runs until every incomplete execution for that scenario is resolved, then resumes normal scheduling once none remain, per options related to incomplete executions. For a webhook-triggered scenario in this state, newly arriving requests continue to accumulate in the webhook queue rather than being dropped. This is the same setting covered in depth in MetaFlowKit’s webhook concurrency guide; this article limits itself to how it interacts with unresolved incomplete executions specifically.

Recovery procedure for a temporary failure

Use this sequence for one synthetic example: a module writing to a fictional billing API returns ConnectionError after the API becomes briefly unreachable.

1. Open the incomplete execution and capture the full evidence checklist above before taking any action.
2. Confirm the error class matches a documented temporary type eligible for automatic retry.
3. If automatic retry is pending, check the scheduled time and allow it to proceed rather than retrying manually in parallel.
4. If automatic retry is not pending or has already been exhausted, confirm the external service is reachable again, then trigger a manual retry from the incomplete execution.
5. After the retry completes, open the resulting execution and confirm the previously failing module now shows a successful status with the expected output bundle.

Bulk-retry and backlog safety

Never bulk-retry a backlog of unresolved incomplete executions until you have classified the underlying cause, confirmed the downstream system’s current capacity to absorb a burst of retried work, and assessed duplicate-effect risk for the specific modules involved. A backlog that accumulated because of a single root cause, such as one connected app outage, is a very different risk profile from a backlog with several unrelated causes mixed together, and bulk-retrying the second kind can turn one investigation into several simultaneous incidents.

• Group the backlog by error class and failing module before deciding on any bulk action.
• Confirm the target external service’s current status before retrying a batch tied to that service.
• Retry a small representative batch first and verify outcomes before retrying the remainder.
• Document which incomplete executions were retried, resolved manually, or deleted, and why.

Verification and reconciliation

After a retry or manual resolution, confirm the outcome against the target system’s own record rather than assuming success from Make’s status alone.

• The incomplete execution’s status shows Resolved in Make.
• The downstream system’s record for the affected item matches the expected single outcome, checked against a stable identifier.
• No duplicate record exists in the destination system for the same identifier.
• Remaining bundles in the original run, if any, completed successfully after the retry.

Retried module work can create additional processed activity depending on current module-level credit rules; treat actual scenario history and credit usage as the source of truth rather than assuming a fixed retry-credit formula, and use How Make Operations Work or the Automation Usage Calculator only to sanity-check the usage impact, not to diagnose the failure itself.

FAQ

Does every failed scenario become an incomplete execution?

No. Whether one is created depends on scenario settings, the error type, any attached error handler, first-module conditions, and storage availability. Confirm storage is enabled and check the specific failure before assuming an incomplete execution exists.

What is the difference between retrying and manually resolving an incomplete execution?

Retry runs the incomplete execution again from the failing module using the same configuration that was in place when it failed. Manual resolution lets you inspect and fix the failing module first, then run from that point using the original input.

Does automatic retry start over from the beginning of the scenario?

No. It restarts at the module that caused the error, not at the first module of the scenario, so steps that already succeeded are not automatically repeated by the retry itself.

Is it safe to retry any incomplete execution that has a temporary-sounding error?

Only for the documented temporary error classes, and only after confirming the underlying condition, such as an outage, has actually cleared. A data or configuration error will typically fail again on retry until it is corrected manually.

Can I bulk-retry a large backlog of incomplete executions safely?

Only after classifying the causes, confirming downstream capacity, and assessing duplicate-effect risk. Retrying a small representative batch first and verifying the outcome is safer than retrying an entire mixed backlog at once.