Zapier Code Timeout: Why Scripts Fail at 30 Seconds (And the Fix)
Code by Zapier steps time out after 1 second on the Free plan, 10 seconds on Starter, and 30 seconds on Professional, Team, and Company plans — a hard ceiling regardless of what the script is doing.
The common workaround is splitting the task across two Zaps connected by a webhook, which works but adds fragility. Latenode’s JavaScript node has no fixed per-step timeout; it bills by actual execution time instead of failing at a fixed clock.
Already know what you need?
Keep the script in Zapier’s Code step, or move it to Latenode where there’s no fixed timeout.
Somewhere between “this Zap works perfectly in testing” and “this Zap has been running in production for three months,” a lot of builders hit the same wall: a Code by Zapier step that ran fine on small data suddenly starts failing with a timeout error on larger payloads.
The frustrating part isn’t that it failed — it’s that the ceiling is fixed and non-negotiable no matter how close the script was to finishing.
Zapier’s Code step limits by plan vs Latenode
| Limit | Zapier Free | Zapier Starter | Zapier Pro/Team/Company | Latenode |
|---|---|---|---|---|
| Code step timeout | 1 second | 10 seconds | 30 seconds | No fixed ceiling |
| Memory limit | 128 MB | 256 MB | 256 MB | Scales with plan |
| Rate limit | 10 runs / 60 sec | 75 calls / 10 sec | 225 calls / 10 sec | Credit-based, no hard call cap |
| Loop iteration cap | 500 iterations (Looping by Zapier), no self-serve increase | No fixed iteration cap | ||
| HTTP requests per code step | 2, unless a custom Zapier app is built | Unlimited within execution time | ||
| Billing model | Per task, regardless of code duration | Per execution time (~1 credit/30 sec) | ||
The exact timeout, by plan
These numbers come directly from Zapier’s own documentation and haven’t been rounded or estimated:
Free plan
1 sec
128 MB RAM, 10 runs/60 sec
Starter plan
10 sec
256 MB RAM, 75 calls/10 sec
Pro / Team / Company
30 sec
256 MB RAM, 225 calls/10 sec
The 30-second ceiling on higher plans isn’t the original limit — Zapier raised it from 10 seconds after enough users on Professional, Team, and Company plans reported hitting it.
That history is worth noting: even Zapier’s own product team has acknowledged the ceiling causes real problems, and the fix so far has been raising it once, not removing it.
Why the timeout exists
Code by Zapier steps run inside a sandboxed serverless environment. That architecture is what makes it safe to let any user run arbitrary JavaScript or Python without risking Zapier’s own infrastructure — but serverless functions are built around short, fast executions by design.
The timeout isn’t a bug or an oversight. It’s a direct consequence of the underlying architecture, which is also why it applies uniformly regardless of what the code is doing — parsing a small JSON object and calling a slow third-party API both run inside the same fixed window.
The workarounds people use today
Zapier’s own community forum has multiple threads from builders working around this in production. The most common pattern:
- Split the task across two Zaps. The first Zap does part of the work, then sends the remaining data to a webhook and ends. A second Zap, triggered by that webhook, picks up where the first left off.
- Use Zapier’s callback service for long API calls. Zapier’s platform docs describe an asynchronous callback pattern for actions that can’t finish within 30 seconds — the action performs the work externally and posts back to a callback URL when done, with the Zap showing a “Waiting” status in the meantime.
- Move to a private Zapier app. Custom apps built on Zapier’s developer platform get a separate 30-second timeout window for their own action’s perform method, which doesn’t help a plain Code step but is an option for teams willing to build a full custom integration.
Where this breaks down
One builder on Zapier’s own forum described being stuck mid-project: an LLM call that couldn’t be split into smaller chunks, a 30-second timeout that couldn’t be raised, and no clean way to keep the task inside a single Zap.
The two-Zap webhook relay works, but it turns one automation into two, each with its own failure points to monitor.
Latenode: no fixed per-step timeout
Latenode’s JavaScript node doesn’t impose a fixed ceiling the way Zapier’s Code step does. Instead of failing at a fixed clock regardless of payment tier, it bills by actual execution time — roughly 1 credit for every 30 seconds of processing.
Zapier’s model
Fixed timeout, same regardless of task
A script gets 1, 10, or 30 seconds depending on plan. If the task needs more time than that, it fails — no amount of extra payment on the Code step itself extends it further.
Latenode’s model
Pay for the time you actually use
A script that needs 90 seconds simply costs more credits than one that needs 10. There’s no separate ceiling to hit — the constraint is cost, not a hard failure point.
Try Latenode →This also removes the loop-iteration problem. Zapier’s Looping by Zapier caps at 500 iterations with no self-serve increase, and a Code step looping internally is still bound by the same time-based ceiling.
A JavaScript node in Latenode processes the loop as part of its own execution time, so the constraint scales with how long the data actually takes to process rather than an arbitrary count.
Rebuilding a timeout-prone Zap in Latenode
- Identify the exact step that times out. Check the Zap’s run history for the “Task timed out after X seconds” error to confirm it’s the Code step and not a different action.
- Recreate the trigger. If the Zap starts from a webhook, add a Trigger on Webhook node in Latenode and confirm it receives the same payload using the Development URL.
- Move the code as-is into a JavaScript node. Most Node.js code written for Zapier’s Code step runs with little to no modification in Latenode’s JavaScript node, since both are Node.js environments.
- Remove any webhook-relay workaround. If the Zapier version was split into two Zaps to dodge the timeout, that logic can usually collapse back into a single Latenode scenario, since there’s no per-step ceiling forcing the split.
- Test with realistic data volume, not just the small sample that worked fine in Zapier before the timeout started appearing at scale.
When it’s worth moving
A Code step that reliably finishes in under a few seconds has no reason to move — Zapier’s ecosystem and ease of use are still genuine advantages for straightforward automations.
The timeout only becomes a real problem once a script’s runtime depends on variable data size: API calls that occasionally run slow, loops over growing datasets, or LLM calls that can’t be chunked without losing context.
If that describes a recurring pattern rather than a one-off script, it’s worth reading through our Latenode migration guide for the full webhook setup process, since the same webhook-first approach applies whether the scenario is coming from Make or from Zapier.
Tools referenced in this guide
One link below is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you.
Current platform
Zapier
Fast setup and the largest app library, with a fixed Code step timeout of up to 30 seconds depending on plan.
Visit Zapier →No timeout ceiling
Latenode
JavaScript node billed by execution time instead of a fixed per-step timeout, with 1.2 million+ NPM packages built in.
Try Latenode →Frequently asked questions – Zapier Code Timeout
How long can a Code by Zapier step run before it times out?
It depends on plan. Free plan Code steps time out after 1 second. Starter plans get 10 seconds. Professional, Team, and Company plans get 30 seconds, which was raised from a previous 10-second limit after user requests. These limits apply regardless of what the code is doing or how close it is to finishing.
Can you increase Zapier’s Code step timeout beyond 30 seconds?
Not through account settings. Zapier does offer extended runtimes for action steps that can run up to 10 minutes total, but this applies specifically to certain action steps rather than Code steps generally, and isn’t a simple toggle available to every plan. For most users hitting the Code step ceiling, the practical options are restructuring the code, splitting work across multiple Zaps connected by webhooks, or moving the logic to a platform without a fixed per-step timeout.
What is the workaround people use for Zapier’s code timeout?
The most common workaround is splitting a long-running task across two Zaps: the first Zap sends data to a webhook and ends, and a second Zap, triggered by that webhook, continues the work. This avoids the single-step timeout but adds complexity, extra steps to maintain, and more places for a workflow to break.
Does Latenode have the same code execution timeout as Zapier?
No. Latenode doesn’t impose a fixed per-step timeout like Zapier’s 30-second ceiling. It bills by actual execution time, roughly 1 credit per 30 seconds of processing, so a script that needs more time simply uses more credits rather than failing outright.
Is Zapier’s 500-iteration loop limit related to the code timeout?
They’re separate limits that often show up together. Looping by Zapier caps out at 500 iterations per run, with no self-serve way to raise it. A Code by Zapier step looping internally isn’t capped at 500 iterations, but it is bound by the same 1, 10, or 30-second timeout, so a loop processing enough records to need more time hits the timeout before it hits the iteration cap.
Disclosure: CreatorOpsMatrix is an independent technical publication. The Latenode link on this page is an affiliate link. If you sign up through it, we may earn a commission at no extra cost to you. The Zapier link is provided for reference only and is not an affiliate partnership.