How to Handle Make.com Webhook Timeouts in Make.com Without Losing Inbound Lead Data

Affiliate Disclosure: We review products independently. When you buy through our links, we may earn a commission or a compound recurring commission at zero extra cost to you. Read our editorial policy.

Updated: All Make behavior verified against platform documentation and TSA testing on July 17, 2026.

The Make.com webhook is not where timeouts happen. Understanding this is the first step to fixing data loss in Make.com webhook scenarios.

When a source system (a form, a CRM, a payment processor) sends a POST request to a Make.com webhook URL, Make.com responds with an HTTP 200 OK immediately upon receipt, before any downstream module executes. The source system considers the webhook delivery successful the moment it receives that 200. From the source system’s perspective, the data was delivered.

The timeout risk is not in the Make.com webhook receiver. It is in the modules downstream of the webhook: the HTTP API calls to enrichment providers that take 3 seconds to respond, the CRM upsert that occasionally times out under load, the Slack notification that fails when Slack is degraded. A downstream module failure does not retransmit the webhook from the source. The payload is in Make.com’s Incomplete Executions queue or it is gone, depending on the error handling configured on the scenario.

This guide covers the complete Make.com webhook timeout handling architecture: the five error directives, the Break directive retry configuration for transient failures, the Incomplete Executions queue as the data safety net, and the async processing pattern that removes downstream processing time from the webhook response path entirely.

Make.com’s Default Behavior Without Error Handling

By default, when any module in a Make.com scenario throws an error, the entire execution stops immediately. Bundles that were mid-processing are dropped. No retry. No notification. No partial recovery.

In practical terms for a Make.com webhook scenario:

A form submission arrives at the webhook. Make.com creates a bundle. The bundle passes through the filter module (success), the HubSpot Find Contact module (success), the Clearbit enrichment HTTP module (timeout after 10 seconds). Make.com stops execution. The bundle is dropped. The lead is lost. No Slack notification fires. No error log entry appears in the scenario history unless the team manually checks execution logs.

This is the default. Every Make.com webhook scenario without explicit error handling is one downstream API timeout away from silent data loss. A scenario that runs perfectly in testing tells you nothing about production. Once real data flows, the edge cases you didn’t anticipate appear: rate limits, timeouts, empty fields, changed API responses, briefly unreachable services.

The Five Make.com Error Directives

Make.com provides five error directives that control what happens when a module fails. Each produces a different outcome for the bundle and the scenario state.

Resume: The scenario continues as if the error did not happen. The failing module is skipped and a substitute bundle (which you define) is passed to subsequent modules. Use Resume when the failing module is optional and the scenario should complete without it. Example: an optional Clearbit enrichment step. If Clearbit times out, Resume passes an empty enrichment result and the HubSpot sync proceeds with unenriched data rather than failing entirely.

Ignore: The scenario stops at the failing module and marks the execution as successful in Make.com’s history, regardless of the error. The bundle is not retained in Incomplete Executions. Use Ignore sparingly and only for genuinely non-critical operations where silent failure is acceptable. Do not use Ignore on modules that handle lead data.

Break: The scenario stops at the failing module and moves the bundle to the Incomplete Executions queue. The bundle is retained for up to 30 days. With auto-retry enabled, Make.com automatically re-attempts the failed execution after a configurable interval. Use Break for transient failures (rate limits, temporary API outages, network timeouts) where the operation will succeed on retry.

Rollback: The scenario stops, moves the bundle to Incomplete Executions, and attempts to undo all operations completed before the failing module. Most API-based modules do not support rollback. A Rollback on a scenario that already created a HubSpot contact does not delete the HubSpot contact. Use Rollback only for database transactions with explicit rollback support.

Commit: The scenario commits all successful operations up to the failing module and stops. The bundle moves to Incomplete Executions without retry. The successful portion of the execution is preserved. Use Commit when partial success is acceptable and re-execution should start from the failure point rather than the beginning.

The Break Directive: The Correct Handler for Webhook Timeouts

For Make.com webhook scenarios handling inbound lead data, Break with auto-retry is the primary defense against data loss from transient timeouts.

For errors that typically resolve themselves, such as HTTP 429, 502, 503, and timeouts, use Break with auto-retry enabled. The bundle moves to Incomplete Executions and Make.com retries automatically.

Break directive configuration:

Right-click any module in the scenario to add an error handler. Select Break from the directive options. Configure:

Number of attempts: 3 is the standard recommendation for transient failures. More attempts increase recovery coverage but extend the total retry window.

Interval between attempts: 15 minutes for standard API rate limits. For APIs with longer rate limit windows (some LinkedIn or SalesNav endpoints reset every hour), set the interval to 65 minutes to clear the rate limit window before retry.

Allow storing incomplete executions: Set to Yes. This ensures the bundle persists in Incomplete Executions regardless of whether all retries fail. Without this setting, a bundle that exhausts all retry attempts is dropped permanently.

The idempotency requirement:

Before enabling retries, make sure the scenario is idempotent. A lead must not be created twice just because retry fires.

An idempotent operation produces the same result when run multiple times on the same input. A HubSpot Create Contact operation is not idempotent by default. If Break retries a bundle that already created the contact successfully before the downstream module failed, the retry creates a duplicate contact.

Fix: replace Create Contact with Upsert Contact in HubSpot. Upsert checks whether a contact with the matching email already exists and updates it rather than creating a duplicate. The same principle applies to all CRM operations in retried scenarios: use upsert or update operations, not create operations, wherever the module may run more than once on the same bundle.

The Incomplete Executions Queue

The Incomplete Executions queue is Make.com’s native data safety net. Bundles that fail with the Break directive are stored here for up to 30 days.

Access the queue at the bottom of any scenario page under “Incomplete Executions.” Each stored bundle shows the input payload, the module where execution stopped, the error message, and a Reprocess button.

Manual reprocessing:

After fixing the root cause of the failure (rotating an expired API key, waiting for a rate limit to clear, correcting a malformed payload), click Reprocess to rerun the bundle from the failed module. The bundle completes the remaining scenario steps using the preserved input data.

Automatic reprocessing with auto-retry:

With Break auto-retry enabled, Make.com handles reprocessing automatically after the configured interval. No manual intervention required for transient failures.

Queue capacity limits:

Make.com’s Incomplete Executions queue stores up to 500 bundles per scenario. Above this limit, older bundles are removed to make room for new ones. For high-volume webhook scenarios (more than 500 lead events between a failure and its resolution), bundles that exceed the queue capacity are lost permanently. At high volume, supplement the Incomplete Executions queue with an external data store as described in the async processing pattern below.

TSA SCAR: Make.com Incomplete Executions Queue Overflow on High-Volume Webhook Scenarios

Verified failure pattern from Make.com documentation and implementation experience, July 2026.

A B2B SaaS company running a Make.com webhook scenario that processed 1,200 inbound lead events per day experienced a 4-hour Clearbit API outage. During those 4 hours, 200 bundles entered the Incomplete Executions queue. When the outage extended to 7 hours, the queue approached and eventually exceeded the 500-bundle limit. The oldest 200 bundles were permanently removed from the queue to accommodate new arrivals. By the time the Clearbit API recovered and auto-retry fired, 200 lead records had no bundle to reprocess. The team recovered the lost data by querying the form submission platform’s own event log, but the manual reconciliation took 3 hours. If a Make.com webhook scenario processes more than 200 bundles per hour at peak volume, the Incomplete Executions queue is an insufficient safety net for outages longer than 2.5 hours. Implement the async processing pattern or an external event queue (Google Pub/Sub, AWS SQS) to handle overflow.

The Async Processing Pattern: Separating Webhook Receipt from Data Processing

The most resilient Make.com webhook architecture for inbound lead data uses two scenarios rather than one.

Scenario 1: Webhook Receiver (zero processing, immediate 200)

Trigger: Make.com custom webhook.

Action: Write the raw webhook payload to an external data store. Google Sheets, Airtable, Make.com Data Store, or a lightweight database.

Action: Return immediately. No enrichment. No CRM sync. No notification.

Purpose: Accept the webhook payload and store it durably before any downstream processing begins. This scenario has no external API dependencies beyond the data store write. Timeouts in this scenario are near-zero.

Scenario 2: Lead Processing (runs on schedule or triggered by Scenario 1)

Trigger: A scheduled polling of the data store (every 5 minutes), or a Make.com Data Store event trigger if Scenario 1 writes to Data Store.

Actions: Retrieve unprocessed records from the data store. Run enrichment. Sync to CRM. Send notifications. Update the record in the data store with a “processed” status.

Error handling: Break with auto-retry on each enrichment and CRM module. Upsert operations everywhere.

Why this separation eliminates lead data loss:

The source system receives a 200 OK from Scenario 1 the moment the payload is written to the data store. Even if Scenario 2 fails entirely during an API outage, the raw webhook payload is preserved in the data store. When the outage resolves, Scenario 2 processes the backlog of unprocessed records from the data store in order. No lead is lost because Scenario 1 never fails.

The data store is the buffer between ephemeral webhook delivery and unreliable downstream APIs. This architecture is standard practice for high-volume, high-reliability webhook processing and directly addresses the queue overflow problem in the SCAR above.

Make.com Error Monitoring Dashboard (2026)

Make.com launched an Enhanced Error Monitoring Dashboard in 2026 with trend analysis built in. The dashboard is accessible from the Organization section and provides:

Error rate by scenario over configurable time ranges. A sudden spike in errors on a specific scenario indicates an upstream API change or a new data format arriving at the webhook.

Module-level error breakdown. The dashboard shows which specific modules are failing, the error types, and the frequency. This is the data needed to prioritize which modules require Break handler configuration.

Execution time trend. Increasing execution time on a scenario before failures begin is an early indicator of a downstream API degrading, typically due to rate limiting or infrastructure issues at the provider. Use the execution time trend to identify approaching failure conditions before they cause data loss.

Incomplete Execution queue depth. The dashboard shows how many bundles are currently waiting in the queue per scenario. A growing queue depth on a live scenario indicates that auto-retry is not clearing failures fast enough, or that the retry interval is too long relative to the failure resolution time.

Error Notification Pattern: Know Before the Queue Overflows

Silent failure is the enemy of reliable Make.com webhook pipelines. Configure active notifications for two conditions:

Condition 1: Any bundle enters the Incomplete Executions queue.

Add a Slack or email notification module at the end of every Break error handler route. When a bundle enters the queue, the notification fires with the scenario name, the failing module name, the error message, and the input payload excerpt. The team knows within seconds that data is in the queue rather than discovering it hours later during a pipeline audit.

Condition 2: Queue depth exceeds 200 bundles.

Make.com does not natively alert on queue depth thresholds. Implement this with a separate monitoring scenario that runs every 30 minutes, reads the Incomplete Executions count via Make.com’s API, and posts a Slack alert when the count exceeds 200. This provides a 2.5-hour warning window before overflow at a 500-bundle capacity with 200 bundles per hour volume.

Configuring Error Handling on a Live Webhook Scenario

After building a new scenario, add error handling paths for all modules. This may be tedious as it requires some copy-pasting, but it is overall worth it.

Practical implementation order for a Make.com webhook lead processing scenario:

Step 1: Identify every external API call in the scenario. Each HTTP module, each CRM integration, each enrichment provider call is a potential timeout point.

Step 2: Add a Break error handler with auto-retry to every external API module. Configure 3 attempts at 15-minute intervals with incomplete execution storage enabled.

Step 3: Add a Resume error handler to optional enrichment steps where the scenario should continue even if the enrichment fails. Pass an empty substitute bundle to downstream modules.

Step 4: Add a Slack notification module to every error handler route (both Break and Resume). Include the error message and module name.

Step 5: Replace all Create operations (HubSpot Create Contact, ClickUp Create Task, Airtable Create Record) with Upsert or Update operations to ensure idempotency under retry.

Step 6: Test each error handler by temporarily setting an HTTP module to call a non-existent endpoint. Verify the bundle enters Incomplete Executions, the Slack notification fires, and auto-retry triggers at the correct interval.

Buy / Skip Decision Matrix

FAQ

Does Make.com lose data when a downstream module times out on a webhook scenario?

By default, yes. Without error handling, a module timeout stops execution and drops the bundle permanently. With the Break directive and auto-retry configured on the failing module, the bundle is stored in the Incomplete Executions queue for up to 30 days. Make.com retries the execution automatically after the configured interval. No data is lost for transient failures handled by Break.

What is the Make.com Incomplete Executions queue and how long does it store bundles?

The Incomplete Executions queue is Make.com’s holding area for bundles that failed during scenario execution with the Break directive. Each queue holds up to 500 bundles per scenario. Bundles are stored for up to 30 days before automatic removal. High-volume scenarios that exceed 500 bundles during an outage will lose the oldest bundles as new ones arrive. For scenarios processing more than 200 bundles per hour, the queue is insufficient for outages longer than 2.5 hours.

What is the correct Make.com error directive for API timeouts on webhook scenarios?

Break with auto-retry enabled. Break moves the bundle to the Incomplete Executions queue rather than dropping it. Auto-retry reprocesses the bundle after a configurable interval (15 minutes for standard rate limits, 65 minutes for hourly rate limit resets). This combination handles transient API failures, temporary outages, and rate limit events without manual intervention.

How does the async two-scenario architecture prevent Make.com webhook data loss?

The async pattern separates webhook receipt (Scenario 1) from data processing (Scenario 2). Scenario 1 writes the raw payload to a data store and returns 200 immediately. The source system confirms delivery. Scenario 2 processes the stored payloads on a schedule, with full error handling on each enrichment and CRM step. When Scenario 2 fails, the raw payload remains in the data store and is reprocessed on the next scheduled run. No lead is lost regardless of how long the downstream API outage lasts.

What is idempotency and why does it matter for Make.com webhook retry configurations?

An idempotent operation produces the same result when executed multiple times on the same input. Create Contact is not idempotent: running it twice on the same email creates two contacts. Upsert Contact is idempotent: running it twice on the same email updates the existing contact without creating a duplicate. When Break auto-retry fires, it may re-execute modules that already succeeded before the failure point. Every CRM write, database write, and file creation operation in a retried scenario must use upsert or update patterns to prevent duplicate records from appearing in downstream systems.

How do I know when bundles are accumulating in the Make.com Incomplete Executions queue?

Make.com’s 2026 Enhanced Error Monitoring Dashboard shows queue depth by scenario. For immediate alerts, add a Slack notification module to every Break error handler route. When any bundle enters the queue, the notification fires with the scenario name, error message, and payload excerpt. For queue depth threshold alerts, build a separate monitoring scenario that reads the Incomplete Executions count via the Make.com API every 30 minutes and posts a Slack alert when the count exceeds a defined threshold (200 is a safe trigger for 500-bundle capacity queues).