How to fix the Make HTTP module 40-second timeout error

TL;DR: Make's HTTP module times out individual requests at roughly 40 seconds.

If the upstream API doesn't respond in that window, the module raises a Timeout error and - unless you've added an error handler - the whole scenario goes incomplete. The fix is in two layers: wrap the HTTP module in a Break error handler so transient slowness retries automatically, and redesign the request itself when the API is reliably slower than 40 seconds.

This is a different limit from the 40-minute scenario hard limit - that one bounds the entire run, the 40-second cap bounds one HTTP call.

Why the 40-second timeout fires

The Make community FAQ confirms the cutoff: a Timeout error means the module didn't get a response in roughly 40 seconds. There are three common reasons:

• Genuine server slowness. The endpoint generates a PDF, runs a report, or hits a cold serverless function. It will routinely take 30-90+ seconds.
• Pagination overload. A single GET asking for 10,000 records when the API streams them slowly.
• Transient noise. Brief network blips, the upstream provider's autoscaler is mid-scale, a brief 502/503 cascade. Retrying the exact same call a minute later succeeds.

Layer 1 (Break handler) only fixes the third case. The first two need a different design.

Step 1: Add a Break error handler to the HTTP module

The Break handler is the right tool when timeouts are intermittent. Per Make's documentation, it auto-retries connection and rate-limit errors by default and stores the failed bundle in the Incomplete executions queue.

1. Open the scenario in the Make editor and right-click the HTTP module.
2. Choose Add error handler -> Break.
3. In the Break panel, set Number of attempts (e.g. 3) and Interval between attempts in minutes. The minimum is 1 minute - the field is in minutes, not seconds, which catches first-time users out.
4. Tick Automatically complete execution if you want Make to silently process the retries; leave it off if you'd rather review failures in the Incomplete executions tab first.
5. Open Scenario settings -> enable Allow storing of incomplete executions. Without this flag the Break handler can't queue retries at all.

One nuance worth pinning: when the Break handler retries, it does so as a new execution from the queue, so it does not eat into the current run's 40-minute scenario budget.

Step 2: Redesign the request when the API is reliably slow

If the endpoint genuinely takes 60+ seconds every time, no retry count saves you - every attempt times out at 40s. Three patterns handle this cleanly:

• Paginate or chunk. Replace one big GET with an Iterator + smaller paged calls. Fetching 50 records ten times is almost always faster than fetching 500 once, because each individual call comes back inside the 40s window.
• Switch to async + webhook. Many "slow" APIs (report generators, AI inference, batch jobs) accept a job request and call you back when ready. Make's Custom Webhook trigger is built for this. Trigger the job from one scenario; the webhook fires a separate scenario when the job completes.
• Trigger and poll. When the API returns a job ID immediately but doesn't support webhooks, fire the request, store the job ID, and use a scheduled scenario to poll /jobs/<id> on an interval. Each poll completes in well under 40 seconds.

The async + webhook pattern is the cleanest of the three but only works if the API supports it. Check the vendor's docs for "callback URL" or "webhook" before reaching for polling.

Step 3: Combine Sleep and Resume for explicit timed retries

The Break handler retries asynchronously via the Incomplete Executions queue. If you need retries inline - same execution, sequential, no queue - the community-recommended pattern is a Sleep module followed by a cloned HTTP module with the Resume directive:

1. Add a Resume error handler to the HTTP module instead of Break.
2. Inside the Resume route, add a Sleep module (1-300 seconds) and then a clone of the failed HTTP module.
3. Optionally guard with {{formatDate(now; "X") - formatDate(scenario.executionStartedAt; "X")}} - if the elapsed time is approaching 40 minutes, skip the retry and email yourself instead. That keeps you under the scenario hard limit.

This pattern eats scenario time (Sleep counts toward the 40-minute budget), so it's only viable for short waits. Use Break for anything longer than a few minutes.

How to verify the fix held

Run the scenario manually. In the History tab, expand the HTTP module's run and check for these signals:

• Timeout still fires: the bundle should now appear in Incomplete executions (Break) or in the Resume branch (Sleep + Resume), not as a hard scenario failure.
• Timeout no longer fires after redesign: the request duration in the module's run details should consistently come back under 40 seconds.
• No silent retries-of-doom: if you see the same bundle retrying every minute forever, the API is genuinely down - cap retry count at 3-5 attempts and add an email alert on final failure. Same playbook applies to other persistent HTTP request errors across automation tools.

FAQ

Can I increase the Make HTTP module timeout past 40 seconds?

No. The 40-second cap is enforced by Make's HTTP infrastructure and is not user-configurable. The fix is to redesign the request (chunking, webhooks, polling) so it returns inside the limit.

What's the difference between the 40-second HTTP timeout and the 40-minute scenario timeout?

The 40-second timeout applies to each individual HTTP request. The 40-minute timeout applies to the entire scenario run, regardless of which modules are inside. They're independent - you can hit the 40-minute scenario cap with hundreds of fast HTTP calls, or hit the 40-second cap on a single slow one.

When does the Break error handler not help?

When the API reliably takes longer than 40 seconds every call. Break re-fires the same request later; if it's deterministically slow, every retry will also time out. Use the redesign patterns from Step 2 instead.

How do I retry only on timeout errors and not on 4xx errors?

Add a Router after the error handler with a filter on the error.message or error.code field. Route only timeouts (typically ConnectionError or messages containing "timeout") to the retry branch; route 4xx codes to a dead-letter branch that emails you, since 4xx errors won't fix themselves on retry.

Does the 40-second timeout apply to the Webhook trigger?

No. The 40-second cap is for outbound HTTP requests made by the HTTP module. The Webhook trigger receives inbound calls, and the timeout there is governed by the calling client, not by Make.

Does the timeout count against the 40-minute scenario limit?

The 40 seconds spent waiting on a timeout does count toward the scenario's total runtime. Break-handler retries do not, because they run as separate executions from the Incomplete Executions queue. Sleep + Resume retries do count, because they run inside the original execution.