Make incomplete executions: find, fix and replay failed runs

What an incomplete execution is

When a scenario hits an error, Make can store the unfinished run in the scenario's Incomplete executions tab instead of discarding it. [1] Make Academy says it saves the scenario's blueprint at the time of the error plus the log details, covering module settings and the input and output data up to the failed module. [3] That lets you fix the problem and finish the run without asking the source app to send the data again.

The feature is disabled by default. [1] To turn it on, open Scenario settings from the scenario toolbar and enable Store incomplete executions. [1] Make Academy calls the same setting Allow storing of Incomplete Executions. [3] Do this before you need it; a run that failed while the setting was off cannot be recovered this way.

What Make retries for you

Make retries incomplete executions automatically when the error is a RateLimitError, ConnectionError or ModuleTimeoutError. [2] Other error types are not retried by default and usually need you to change data or settings and resolve them manually. [2]

The automatic schedule is 8 retries measured from the original run: at 1 minute, 11 minutes, 21 minutes, 51 minutes, 1 hour 21 minutes, 1 hour 51 minutes, 4 hours 51 minutes and 7 hours 51 minutes. [2] Up to 3 retries run in parallel per scenario, and a retry waits while the original scenario is running. [2] A successful retry marks the item Resolved; if all attempts fail it is marked Unresolved. [2]

The Retry error handler is a separate tool you add to a module. When automatic run completion is enabled on it, it defaults to 3 attempts with a 15-minute delay, both adjustable. [2]

How much you can store

Storage is pooled across all scenarios in all teams in your organization and depends on your usage allowance. [1] Make's pricing page gives the allowance as 10 MB of incomplete-execution storage per 10,000 credits licensed per month, up to a 2 GB maximum. [5] Each stored item shows its size in the Incomplete executions tab. [3]

When storage runs out, the outcome depends on the data-loss setting. Make Academy says that if data loss is allowed, the scenario keeps running but new incomplete executions are not saved; if not, Make disables the scenario until you resolve existing items to free space. [3] The current help page names the setting Discard data if storage is full and warns that discarded data cannot be recovered. [4]

Worked example: on a 10,000-credit plan you have 10 MB. A scenario that fails 200 times during an outage with 50 KB of data per run fills that space. Clear resolved items and fix the cause before the next outage.

Resolving stored runs step by step

• Open the scenario's Incomplete executions tab and read the status of each item: Unresolved, Pending (scheduled for automatic retry), In progress or Resolved, plus a Scheduled in countdown to the next automatic retry. [3]
• Open one item and read the error on the failed module before touching anything.
• For a data error, edit the failed module or later modules in the stored run; this does not change the original scenario. [3] Then retry.
• Fix the main scenario too, or the next run will fail the same way.
• For many items with the same temporary cause, use bulk retry; Make notes you cannot modify the blueprint in that case. [3]
• Delete an item only when you are sure the data was processed some other way; Make says a deleted incomplete execution cannot be restored. [3]
• Leave resolved items alone; Make deletes them automatically after 30 days. [3]

When replaying causes duplicates

Make says a retry starts from the module that caused the error. [2] Modules before it are not rerun, which protects you from re-sending the first half of the scenario. The risk sits with the failed module itself and with anything you do outside the incomplete execution.

Timeouts are the classic case. A timeout tells you Make stopped waiting, not that the other app did nothing. If the email platform or CRM finished creating the record after Make gave up, the automatic retry creates it again. For create or send actions that time out, check the destination app before resolving, or put a search-before-create step ahead of the action so a replay finds the existing record.

The second case is double recovery. Make Academy notes you can delete an incomplete execution once you have already resent and processed the data. [3] If someone resends the form submission or re-triggers the webhook and the incomplete execution also retries, the record is processed twice. Pick one recovery path per failure and write it down.

A sensible default setup

• Turn on Store incomplete executions for every production scenario that is not marked confidential. [1]
• Keep the data-loss setting off for important scenarios so Make stops rather than silently dropping failures. [3]
• Put idempotent steps (search, then create or update) in front of create and send actions.
• Check the Incomplete executions tab weekly, and after any outage of a connected app.
• Use error-handler routes for expected failures and incomplete executions for unexpected ones; our error-handler guide covers the routes.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Make Help: Incomplete executions Accessed 29 Oct 2026
2. Make Help: Automatic retry of incomplete executions Accessed 29 Oct 2026
3. Make Academy: Incomplete executions Accessed 29 Oct 2026
4. Make Help: Scenario settings Accessed 29 Oct 2026
5. Make pricing Accessed 29 Oct 2026