Zapier12 min readPublished September 2026

Zapier Functions stopped on 1 September: what to do with the code

Zapier retired Functions and left two different statements about who it affected. Moving code to Code by Zapier means re-architecting it, because secrets, packages, runtimes and the SDK all work differently. Here is how to tell whether a Zap is quietly dead.

What was Zapier Functions, and what called it?

Functions was a separate development environment with its own editor, its own Python runtime, stored secrets and a flat monthly task allowance. A Zap reached it through one action, and so could an agent:

With Zapier Functions, you can connect your function code to a Zap or an agent. This allows you to run custom code with access to features like Python packages, secrets, and a full development environment.

That page carries one more line worth knowing, because it explains the whole arc of the product:

This product is in open beta. It's available for use but still in active development and may change.

Functions shipped in beta and was retired in beta. If yours was switched on for you by support, that was normal: one user was still waiting for Functions to be enabled in late March 2026, and Zapier switched it on for them in April, seven weeks before announcing the shutdown.

What Zapier announced, and what Zapier says now

The announcement, published in May 2026 and never revised since, is unambiguous and absolute:

After September 1, 2026, all functions will stop running. Deployed functions will no longer execute, and the Functions interface will no longer be accessible.

On 1 September itself, Zapier stamped a banner onto every article in the Functions section, and it says something narrower:

Zapier retired Functions for most accounts on September 1, 2026. New Function creation and existing Function runs are no longer available. If your account has an active migration extension, you can continue using Functions until your extension ends.

"For most accounts" and "an active migration extension" appear nowhere in the announcement, and Zapier publishes no page explaining who gets an extension, how to request one, or how long it lasts. So the honest reading is this: assume yours stopped, check your own Zap history rather than trusting either sentence, and if your functions are somehow still running, you are inside a carve-out that ends on a date nobody has published.

Two vendor pages, two different scopes, both live today. When that happens, the only reliable source about your account is your account.

The dates leading up to it, from the same announcement: no new sign-ups or new functions after 1 June 2026, existing functions running until 1 September. And one promise with a boundary worth noticing: "No code will be deleted in 2026." That is time-boxed to this calendar year, so copy your code out now if you have not.

How do you tell whether a Zap is quietly dead?

Zapier does not document what a Call a Function step does now - whether it errors, halts, or blocks the Zap from publishing. What is documented is the general behaviour, and it is enough to plan around.

An errored run is not a stopped Zap, at least not immediately:

Your Zap will automatically turn off if 95% of its runs result in errors in the last 7 days.

Read that as a ratio, not a count. A Zap that fails every time it runs is at 100 per cent from its first errored run, whether it runs hourly or twice a week, so the switch-off depends on when Zapier next evaluates the window, not on how many failures pile up. Team and Enterprise accounts get a warning and a grace period first, 24 and 72 hours respectively.

There is also a category that never triggers the safety net at all:

Safely halted - The run purposely stopped, usually because a search step found no results. Unlike errors, safely halted runs will not turn off your Zap.

Safely halted runs are why the check has to be manual this week. Open Zap history, filter to errored and halted runs, and look at what your Zaps have actually been doing since 1 September. Do not wait for the notification, because the notification is not designed to arrive quickly.

Why is nobody posting about broken Functions?

There is no public outcry to search for. A search of the Zapier community for Functions, Call a Function and the shutdown date turns up nothing from anyone whose Zap broke on it.

That silence is consistent with what this kind of failure looks like from the outside. A function called from the middle of a workflow does not announce itself when it stops: the Zap reports an error on a step, the error lands in a history nobody opens, and the business notices when a customer asks why they never got the thing they were promised. Somebody posted a general version of the question on the day of writing:

Not errors, those email you. I mean a Zap that just stops triggering: expired auth, the source app changed something, nothing in the history. I've been burned twice, both times a customer told me before Zapier did.

Moving the code is a rebuild, not a paste

Zapier's migration guide is a set of instructions to a human. There is no converter, and nothing happens automatically:

Copy your function code. From the Functions home, open each function and save your Python code locally before the September 1, 2026 shutdown date.

Each function trigger becomes a separate Zap trigger. If your function had multiple triggers, create one Zap per trigger or share code logic in a sub-Zap.

The two lines in that guide that decide how big the job is are easy to skim past. The first is about credentials:

Code by Zapier cannot store secrets like API keys in your code. If you need to call an app Zapier does not support, or an API endpoint that is not in the standard app integration, use API by Zapier with the Zapier SDK. That is the safest way to make authenticated calls without putting credentials in your code.

Functions stored secrets. Code by Zapier does not, so any function that authenticated to an outside API is re-architected rather than pasted.

The second is about language, and it catches Python functions specifically. The guide's own comparison table maps the old authenticated-call helper to the Zapier SDK, and marks that SDK "JavaScript only". A Python function that called app actions cannot stay Python.

What are the Code by Zapier limits?

Functions had its own environment. Code steps run inside the Zap, on a smaller footprint, and these are the walls people hit when porting:

LimitWhat the docs sayWhy it bites
Runtime by plan"Free 1 second" / "Professional 30 seconds" / "Team 30 seconds" / "Enterprise 2 minutes"A five-minute Function has nowhere to go on the default settings
Extended runtime"Code by Zapier action steps can run for up to 10 minutes using extended runtimes" on paid plansOpt-in, actions only, and billed - it began phasing in with billing on 15 June 2026
Memory and I/O"512 MB" on every plan; "an I/O limit of 6 MB. The total size of the code and the data processed by the Code step cannot exceed that"Large payloads that a Function handled will fail here
Packages"Only ESM (ECMAScript Module) JavaScript packages are supported" and "Native modules are not supported"A dependency your Function relied on may have no working equivalent

All four limits above come from Zapier's Code by Zapier documentation, listed in Sources.

The money moves too, and it is easy to miss because it sits in one row of that same table. A Functions plan came with a flat allowance of 1,500 tasks a month. Code steps consume ordinary Zap tasks, which the migration guide states as "Standard task usage applies". If your function ran on every record, your task consumption changes shape.

Which Python are you actually getting?

Two live Zapier pages disagree, and the answer matters if your code uses anything modern. The current Code by Zapier page says "Only JavaScript (Node.js 22) and Python 3.13 are supported". The older per-language page, still published, still says the environment is "vanilla Python 3.7.2" and that "You cannot install additional libraries or pip modules directly" - while the packages page says public PyPI packages work on paid plans.

Both are vendor documentation, both were live on 6 September 2026, and nothing reconciles them. Which means the version and the package support are things to test in a scratch Zap before you plan a port around them. Ten minutes with a Code step that prints its own version settles it for your account, and that is a more reliable answer than either page.

How do you migrate a function to Code by Zapier?

  1. Find your copy of the code. If you exported before 1 September, it is in your files. If you did not, the interface is gone and the only thing you have to work with is Zapier's promise that no code will be deleted in 2026 - which makes this a support request, and one worth making early. December is a bad month to discover the promise had an end date.
  2. List the Zaps and agents that call a function. Agents are in scope, because the same action was available as an agent tool. Zapier documents nothing about how an agent behaves once that tool is retired, so check the agent by using it, not by reading its configuration.
  3. Check Zap history since 1 September for errored and halted runs rather than waiting for the automatic switch-off, which needs a 95% error rate over seven days.
  4. Decide per function whether it should be code at all. Some Functions were doing a job that current Zapier actions now cover, and the migration is then a deletion, which is the cheapest outcome available.
  5. Handle secrets first. Anything holding an API key needs the API by Zapier route, and that decision shapes the rest of the rebuild.
  6. Test with real data before you turn anything on. A ported step that passes its test and fails on the first live record is the standard way this goes wrong, and the causes are documented.
  7. Watch the first live runs deliberately. The failure you are guarding against is silent, so the check has to be active.

When this is a job to hand over

One small function, ported into a Code step, tested on a real record - that is an afternoon, and worth doing yourself.

It becomes a job when there are a dozen of them, when the code came from someone who has left and nobody can say what it does, when secrets are involved and the rebuild has to run through API by Zapier, or when the Zaps have been failing since 1 September and something downstream has been quietly wrong for a fortnight. Those are bounded pieces of work with a known price and a known deadline, which is what Fix S and Fix M are for, and the Zapier work we take is scoped this way.

This is the second vendor shutdown in a week for anyone running both platforms: OpenAI switched the Assistants API off on 26 August, and the Zapier actions built on it stopped the same day. The wider habit is worth building whatever you do about Functions: a vendor changing something under a working automation is the normal case, and the notice always arrives addressed to whoever built it rather than to whoever depends on it.

Sources

  • Important update: Zapier Functions is being deprecated - Zapier Help Center, updated 29 May 2026, read 6 September 2026. The three dates, the statement that all functions stop running after 1 September 2026, and the promise that no code will be deleted in 2026.
  • Call a function from Zap workflows or agents - Zapier Help Center, banner dated 1 September 2026, read 6 September 2026. What the action did, its availability to agents, its open-beta status, and the retirement banner naming "most accounts" and migration extensions.
  • Migrate from Zapier Functions to Code by Zapier - Zapier Help Center, updated 13 July 2026, read 6 September 2026. The manual migration steps, one Zap per trigger, secrets having no equivalent, the Zapier SDK being JavaScript only, and standard task usage.
  • Using Code by Zapier - Zapier Help Center, updated 13 July 2026, read 6 September 2026. Supported languages, the runtime and memory table by plan, and extended runtimes being limited to actions.
  • Use JavaScript code in Zap workflows - Zapier Help Center, read 6 September 2026. The 6 MB input and output limit of the execution environment.
  • Use third-party packages in Code steps - Zapier Help Center, updated 29 May 2026, read 6 September 2026. Paid-plan requirement, ESM-only packages, no native modules, no private registries.
  • Configure extended runtimes for Code steps - Zapier Help Center, updated 15 June 2026, read 6 September 2026. Extended runtimes for actions only, phased enablement and billing from 15 June 2026.
  • How to troubleshoot errors in Zap workflows - Zapier Help Center, updated 29 May 2026, read 6 September 2026. Errored versus safely halted runs, the 95% over seven days auto-off rule, and the grace periods on Team and Enterprise plans.
  • Use Python code in Zap workflows - Zapier Help Center, updated 29 May 2026, read 6 September 2026. The page still describing a vanilla Python 3.7.2 environment with no additional libraries, contradicting the current Code by Zapier page.
  • Can not get Functions feature in the account - Zapier Community, 28 March to 9 April 2026, read 6 September 2026. A user waiting weeks for Functions to be enabled on their account, and Zapier support enabling it, seven weeks before the deprecation was announced.
  • How do you catch a Zap that silently stopped? - Zapier Community, 6 September 2026, read 6 September 2026. The failure mode this shutdown produces, described by someone who has been caught by it twice.

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.