An incomplete executions queue is easy to ignore until the day it stops your scenario from running at all. The queue is a safety net, but it is a safety net with a capacity and with side effects on scheduling, and both of those are governed by settings most people never open.
This is what each option in that queue actually does, and which of the two related settings you should check before you touch any of it.
Paste your logs into the Free Analyzer to check this: analyze your logs free.
What an incomplete execution actually is
Incomplete executions are a safety feature that protects a scenario from stopping because of an error, and protects you from the data loss that an error can cause: with them enabled, Make stores the unfinished scenario run in the incomplete executions tab. The failed run is not gone, it is parked with its data intact.
The first thing worth knowing is that incomplete executions are disabled by default, and storing them requires enabling the “Store incomplete executions” option in the scenario’s settings. A scenario that has never had that switch turned on has no queue to check, which means failures there simply did not survive.
To find the queue, select the scenario and switch from the diagram tab to the incomplete executions tab. Each entry carries an incomplete execution ID, the date and time it was created, its size (the blueprint plus the data the module was processing when it failed), and a status.
What do Retry, Resolve, and Delete each commit you to?
Before choosing between them, answer one question: do you want the remaining steps of that run to execute at all? When dealing with incomplete executions, the first decision is whether you want to finish the run and process the rest of the data.
If the answer is no, because the record was a duplicate, a test, or something already handled by hand, deletion is the correct action and the rest of this section is irrelevant. If the answer is yes, the next question is whether the failure can recur, and that decides retry versus manual resolution.
The three options are not three flavours of the same thing.
Retry re-attempts the run. Retrying an incomplete execution is another attempt to run the scenario, and it runs with the same module settings as when the error happened. That last clause is the one that matters: retry changes nothing about your configuration. It is the right choice when the failure was environmental rather than structural. If the error is a temporary one, such as a ConnectionError or a RateLimitError, you can retry the incomplete executions, and you can retry several at once.
Resolve is for the opposite case. If the error requires changes in the module settings or in the general scenario blueprint, you need to resolve the incomplete execution manually. Retrying a structurally broken run just reproduces the same failure with a fresh timestamp.
Delete discards the parked run. If you find that you do not need to run the rest of the scenario, you can delete the incomplete execution.
Before deciding, read the failure itself: go to the incomplete executions tab, find the entry, click details, and the scenario builder opens where you can click the warning sign on the module that caused the error. That tells you which of the three you are actually choosing between.
What do the queue statuses tell you?
An entry’s status is not decoration. Unresolved means the incomplete execution is not set to retry and has not been resolved; pending means it is set to retry, and the “scheduled in” column shows approximately when Make will retry it. There is also an in-progress state for one currently running.
The practical consequence is that a queue full of pending entries needs patience, not intervention, while a queue full of unresolved entries needs a decision from you. Clearing a queue without reading statuses tends to mean cancelling retries that were about to succeed.
Why the queue can stop your scenario from running
This is the part that surprises people, and it is a setting, not a bug.
The “Process data in order” option ensures the scenario runs in sequence: if there is an incomplete execution, Make pauses further scheduling of that scenario to keep processing in chronological order, and activates it again once the scenario has no incomplete executions. So on a scenario with that option on, one unresolved entry halts everything until you deal with it. If the scenario has instant scheduling, Make stores the arriving bundles in the webhook queue rather than dropping them.
That is why “my scenario stopped running” and “there is an old entry in the incomplete executions tab” are frequently the same incident. If a scenario has gone quiet, the queue is worth checking before the scheduling switch or anything else.
What is the capacity limit, and which setting decides what breaks?
The queue is finite. The maximum number of incomplete executions across all scenarios in all teams in an organization depends on your usage allowance, and exceeding the limit produces an error message.
What happens at that limit is controlled by one more option. The “Enable data loss” setting controls what should happen when Make cannot create an incomplete execution of a failed run, which in most cases happens because the incomplete execution storage is full. The two outcomes are genuinely opposite. With data loss disabled, Make pauses scheduling of the scenario to avoid losing any more runs, until you clear the storage and enable the scenario again; with data loss enabled, Make continues scheduling the scenario even if it could not store the incomplete execution.
Neither setting is wrong. Disabled trades availability for completeness, enabled trades completeness for availability. What is wrong is not knowing which one a business-critical scenario is running.
How does enabling the queue change automatic retry timing?
There is a second, less obvious consequence of turning the queue on, and it affects scenarios that never reach the queue at all.
When a module outputs a ConnectionError or a ModuleTimeoutError, Make automatically retries the scenario using exponential backoff, a strategy where each failed attempt is followed by a progressively longer wait, and the delays between reruns depend on whether incomplete executions are enabled in the scenario settings. The two schedules diverge quickly: with incomplete executions enabled the reruns fall at one minute, ten minutes, ten minutes, thirty minutes; with them disabled the same reruns fall at one minute, two minutes, five minutes, ten minutes, then an hour.
So enabling the queue is not a neutral safety improvement. It makes early retries less aggressive and later ones more frequent, which is usually what you want for a flaky external API and not what you want for something latency-sensitive.
Which failures never reach the queue?
A queue that looks clean is not proof that nothing failed, because some errors do not create an incomplete execution at all.
The first case is positional. When the error happens on the first module in the scenario, no incomplete execution is created; adding the Break error handler to that first module makes Make store the incomplete execution even when the first module outputs an error. A trigger that fails is therefore invisible in the queue by default, which is exactly the module you would most want a record of.
The second is duration. When a scenario runs longer than the run duration limit for your plan, no incomplete execution is created.
The third is phase. When an error happens during the initialization or rollback phase, there is no incomplete run, because those errors occur outside the operation phase. A connection that fails at initialization falls in this category, which is one reason a stale connection can produce failures with nothing parked to show for them.
Which routine keeps the queue small?
The queue is a process problem more than a technical one, and the fix is not a larger allowance.
Check it on a cadence short enough that it never grows: an entry sitting unresolved for a week is one that has already blocked scheduling, or consumed capacity, or both. When you check, read statuses first and only act on unresolved entries. Retry the environmental failures in a batch, resolve the structural ones by fixing the module and then resolving, and delete anything you have already handled elsewhere. If the same module keeps producing entries, the queue is reporting a real defect and the fix belongs in the error handler attached to that module rather than in the queue.
If you are not sure which category a given failure falls into, comparing that run against the last successful one usually settles it in less time than reading the blueprint.
What does each queue action commit you to?
| Action | What it does | When it is the right choice |
|---|---|---|
| Retry | Runs the stored execution again from where it stopped | The underlying cause is already fixed |
| Resolve | Marks the execution handled without running it | The work was completed another way |
| Delete | Removes the stored execution permanently | The execution is no longer needed at all |
| Leave it queued | Keeps it stored and counting toward capacity | Only while you are still diagnosing |
Limitations
This covers the queue’s behaviour and settings, not the specific errors that fill it; which module is failing and why is scenario-specific. Storage limits depend on your plan’s usage allowance rather than being a fixed number.
Retry semantics apply to Make’s own retry of a stored run, which is a different mechanism from a Retry directive you attach yourself as an error handler. ScenarioTrace’s Free Analyzer reads exported logs and is deterministic-first with AI-assisted reasoning as a fallback, so treat its output as a diagnosis to confirm against your own history.
This article was drafted with AI assistance and checked against cited sources through ScenarioTrace’s editorial workflow.
Make and Make.com are trademarks of their respective owner. ScenarioTrace is an independent tool and is not affiliated with or endorsed by Make.