Make.com Incomplete Executions: Workflow Failure Recovery and Retry Plumbing

Workflow orchestration platforms face a hard problem: when a 12-step automation dies at step 7, what state do you persist, which steps do you replay, and who decides whether to retry automatically or wait for human intervention?

Make.com (a Zapier competitor) solves this with incomplete executions, a storage and recovery system that separates transient network failures from structural errors. The implementation reveals production-tested patterns for handling partial workflow failure in any agent orchestration system.

Incomplete Execution Storage

By default, Make.com discards failed runs. You enable persistence per scenario:

1. Open Scenario settings (gear icon)
2. Set Store incomplete executions to Yes
3. Save

Once enabled, Make.com writes execution state to storage when a run fails mid-workflow. This includes:

• Bundle data (the payload being processed)
• Execution position (which module failed)
• Error type and message
• Timestamp and scenario version

The Retry error handler (formerly called Break) also requires this setting. Without storage, the handler cannot queue bundles for later completion.

Error Classification and Retry Logic

Make.com categorizes errors into two buckets: retriable and non-retriable. The distinction determines whether the platform retries automatically or parks the execution for manual resolution.

Automatic Retry Errors

Make.com retries these error types without human intervention:

• RateLimitError: API quota exceeded
• ConnectionError: Network timeout or DNS failure
• ModuleTimeoutError: Module exceeded execution limit
• Retry handler with automatic completion enabled: Explicit retry request from workflow logic

Retries follow an exponential backoff schedule (times after original run):

1. 1 minute
2. 10 minutes (11 minutes total)
3. 10 minutes (21 minutes)
4. 30 minutes (51 minutes)
5. 30 minutes (1 hour 21 minutes)
6. 30 minutes (1 hour 51 minutes)
7. 3 hours (4 hours 51 minutes)
8. 3 hours (7 hours 51 minutes)

The Retry handler uses a different default: up to 3 attempts with 15-minute delays. You configure both attempts and delay in the handler settings.

Manual Resolution Errors

These errors halt execution and require human intervention:

• DataError: Invalid data format or type mismatch
• BundleValidationError: Schema validation failure
• RuntimeError: Uncaught exception in module code
• Any error not in the automatic retry list

Manual errors usually indicate a blueprint problem (wrong mapping, missing field, incorrect API endpoint) rather than a transient condition.

Replay Behavior and State Recovery

When Make.com retries an incomplete execution, it resumes from the failed module. Earlier modules do not re-run. This matters for workflows with side effects:

• If step 3 writes to a database and step 7 fails, retry starts at step 7
• Step 3 does not write again (no duplicate records)
• Step 7 receives the original bundle data from step 6

This replay-from-failure approach assumes modules are idempotent or that earlier side effects are acceptable. If you need full re-execution, you must manually trigger a new run from the beginning.

Status Taxonomy

Make.com assigns one of four statuses to each execution:

Status	Meaning	Action Required
Success	All modules completed without error	None
Warning	Completed with non-critical issues (e.g., optional field missing)	Review logs, usually safe to ignore
Incomplete	Failed mid-run, stored for retry or manual fix	Check error type, resolve or retry
Error	Failed and not stored (storage disabled or unrecoverable error)	Enable storage or fix blueprint

The Incomplete executions tab shows only incomplete-status runs. You can filter by scenario, date range, or error type.

Manual Resolution Workflow

For non-retriable errors, you fix the problem and then choose a resolution path:

1. Resolve: Mark the execution as handled without re-running (useful when you fixed data externally)
2. Retry: Re-run from the failed module with original bundle data
3. Ignore: Discard the execution (acknowledges the failure but takes no action)

Resolving does not trigger a new run. It updates the status to Success and removes the execution from the incomplete list. Use this when you manually completed the workflow outside Make.com (e.g., you sent the email by hand after an SMTP error).

Retry re-runs the workflow from the failure point. If the underlying issue is fixed (API key updated, endpoint corrected), the execution completes. If the error persists, Make.com creates a new incomplete execution.

Architecture Implications for Agent Orchestration

Make.com’s incomplete execution system demonstrates several patterns useful for agent workflows:

Separate transient from structural errors. Network timeouts and rate limits get automatic retry. Schema mismatches and invalid API calls require human review. This prevents infinite retry loops on unfixable errors.

Persist execution state at failure boundaries. Store enough context to resume without re-running side-effecting steps. For agents, this means saving tool call results, conversation history, and decision checkpoints.

Expose failure modes through status taxonomy. Four statuses (success, warning, incomplete, error) map to clear actions. Agent systems need similar observability: which failures are transient, which need prompt tuning, which need human escalation.

Provide manual override paths. Automatic retry handles 80% of failures. The remaining 20% need human judgment (resolve without retry, retry with modified data, ignore and move on). Agent orchestrators need equivalent escape hatches.

Code Example: Simulating Make.com’s Retry Logic

import time
from enum import Enum
from dataclasses import dataclass
from typing import Optional

class ErrorType(Enum):
    RATE_LIMIT = "RateLimitError"
    CONNECTION = "ConnectionError"
    MODULE_TIMEOUT = "ModuleTimeoutError"
    DATA_ERROR = "DataError"
    RUNTIME_ERROR = "RuntimeError"

@dataclass
class IncompleteExecution:
    bundle_data: dict
    failed_module: str
    error_type: ErrorType
    attempt: int = 0
    max_attempts: int = 8
    
    def is_retriable(self) -> bool:
        return self.error_type in [
            ErrorType.RATE_LIMIT,
            ErrorType.CONNECTION,
            ErrorType.MODULE_TIMEOUT
        ]
    
    def next_backoff_seconds(self) -> Optional[int]:
        """Returns Make.com's exponential backoff schedule."""
        schedule = [60, 600, 600, 1800, 1800, 1800, 10800, 10800]
        if self.attempt >= len(schedule):
            return None
        return schedule[self.attempt]
    
    def should_retry(self) -> bool:
        return (
            self.is_retriable() 
            and self.attempt < self.max_attempts
            and self.next_backoff_seconds() is not None
        )

def process_incomplete_execution(execution: IncompleteExecution):
    """Simulates Make.com's automatic retry logic."""
    if not execution.should_retry():
        print(f"Manual resolution required: {execution.error_type.value}")
        return
    
    backoff = execution.next_backoff_seconds()
    print(f"Attempt {execution.attempt + 1}: Retrying in {backoff}s")
    time.sleep(backoff)  # In production, use a queue with scheduled tasks
    
    execution.attempt += 1
    # Resume from failed_module with original bundle_data
    # (actual retry logic would go here)

Technical Verdict

Use Make.com’s incomplete execution pattern when:

• You run multi-step workflows with external API calls prone to transient failures
• You need to separate automatic retry (network issues) from manual fixes (logic errors)
• You want to avoid duplicate side effects by resuming from failure point
• You need audit trails showing which executions failed and why

Avoid or extend this pattern when:

• Your workflows require full re-execution from the beginning (not just resume-from-failure)
• You need more granular retry policies per module (Make.com applies one schedule to all retriable errors)
• You want conditional retry based on error message content (Make.com only checks error type)
• You need to modify bundle data before retry (Make.com replays original data)

The incomplete execution system works well for linear workflows with clear failure boundaries. For complex agent orchestrations with branching logic, nested loops, or dynamic tool selection, you will need additional state management beyond what Make.com exposes. The core pattern (persist state, classify errors, retry transient failures, surface structural failures) remains sound.

Source Links

• Make.com Incomplete Executions Guide