Make.com "Incomplete Executions" Explained (and How to Clear Them)

The one-paragraph version

An incomplete execution is a Make scenario run that crashed partway through — it completed some modules, then hit an error it couldn't recover from. Make parks it in the Incomplete Executions folder so you can inspect, fix, and retry. They pile up for three reasons: flaky external APIs (rate limits, timeouts), bad data in one record poisoning the whole run, and missing error handlers on modules that fail intermittently. The fix is the same in all three cases: add error handling (break/ignore/resume directives) at the failure points, fix the underlying data, and only then bulk-retry. Details below.

What "incomplete" actually means

A normal run goes: trigger → module 1 → module 2 → done. If module 3 throws an error (API down, invalid data, timeout), Make stops the run and stores everything it completed so far plus the error. The run isn't lost — it's frozen, waiting for you to decide: retry it, or delete it.

Incomplete executions are not the same as filtered-out bundles (those are normal — a filter said "skip this") or disabled scenarios. They're errors that survived to the surface.

Why they pile up (the three usual causes)

1. Flaky external APIs. The most common. A CRM API rate-limits you at 3pm, a webhook target times out, Google's API has a bad five minutes. Your scenario is fine; the world hiccuped. These come in waves — 40 incomplete executions all showing "429 Too Many Requests".

2. One bad record. A single Airtable record with a malformed date, an email field containing "n/a", a null where the API expects a string. Every run that touches it dies at the same module. These show the identical error at the identical module, over and over.

3. No error handling on intermittent failures. Some modules fail occasionally by nature (file downloads, AI API calls). Without an error handler, each failure becomes an incomplete execution instead of a handled blip.

The fix, per cause

For flaky APIs — add a Break error handler with retry:
Right-click the failing module → Add error handler → choose Break. The Break directive retries the module (configurable: attempts and delay between them). Set something like 3 attempts, 5 minutes apart. Transient failures now resolve themselves and never reach the incomplete folder. For rate limits specifically, add a Sleep module before the API call (e.g., 1 second) to stay under the limit.

For bad data — fix the record, then retry:
Find the poisoned record (the incomplete execution shows you exactly which bundle failed and the error). Fix the data at the source, then go to Incomplete Executions, select the run, and Run it again. Don't just delete it — the record still needs processing. For recurring bad-data patterns, add a filter or a data-validation step before the fragile module (e.g., "only continue if email contains @").

For intermittent failures — add Ignore or Resume handlers:

Ignore: the module failed, skip it, continue the scenario. Good for optional steps (e.g., "notify Slack" — if Slack is down, the main work should still complete).
Resume: the module failed, substitute a fallback value, continue. Good when downstream modules need something (e.g., an AI summary that failed → use the raw text instead).

Pick Break for transient, Ignore for optional, Resume for needs-a-value. Most scenarios need a mix.

Clearing the backlog safely

Sort by error message. Group identical errors — one fix often clears dozens.
Fix the cause first, then retry. Retrying before the fix just regenerates the pile.
Bulk retry with "Run" on selected executions once the cause is fixed.
Delete only runs you're sure are obsolete (old test data, superseded records). Deleting a real incomplete execution means that record never gets processed — check first.

How to stop them coming back

Error handlers on every module that touches an external API (Break for transient, Ignore/Resume for optional).
A validation filter before modules that consume user-entered data.
A weekly glance at the Incomplete Executions folder — five minutes, part of the routine, before it becomes fifty.

Verdict

Incomplete executions aren't a Make bug — they're Make doing its job, showing you exactly where reality disagreed with your scenario. Handle errors at the module level, fix bad data at the source, and the folder stays empty on its own.

Based on Make's error-handling model as of October 2026. The Incomplete Executions UI lives under the scenario's "History" / execution queue depending on your plan — names shift, the concept doesn't.

Enjoyed this? Join the newsletter for one practical automation tip a week. No spam, no hype.

← Back to all field notes