Zapier Free Plan: What Ecommerce Ops Actually Get

What the Zapier free plan actually includes

The Zapier free plan connects one trigger app to one action app and runs it on a schedule Zapier sets, not one you choose. You can build as many separate zaps as you like, each linking a different pair of apps, but every individual zap is limited to a single step: one thing happens, then one thing happens in response. There’s no branching, no filtering, no delay step and no way to send one trigger to two different actions from within the same zap.

That single-step ceiling is the plan’s real shape, more than the monthly task allowance most people focus on first. Zapier changes the specific task number on its pricing page periodically, so check it there rather than trusting a figure quoted elsewhere. The task count was never the constraint that stops an ecommerce workflow from working. The step limit is.

For a solo operator wiring up a single alert (a new Shopify order posts a message to Slack, a new email subscriber gets added to a spreadsheet), this is enough. The zapier free plan was built for exactly that: one connection, one action, tested and left running. The trouble starts the moment your workflow needs a second thing to happen, or needs to happen only sometimes.

What the free plan is genuinely good for

The free plan has one legitimate use that gets skipped over in most complaints about it: proving a trigger actually fires before anyone commits time to building the real workflow. Before wiring conditional logic, error handling and a second or third action into a paid multi-step zap, it’s worth knowing the trigger app sends the event you think it sends, in the shape you expect, on the schedule you expect. A free single-step zap that dumps a raw payload into Slack or a spreadsheet answers that question directly: does a Shopify order-created event actually fire when a subscription renews, or only on a first purchase; does a Klaviyo list-add trigger fire on import as well as signup. Those are the kind of surprises that are far cheaper to find on a zero-cost single-step zap than after a paid, multi-step workflow has been built around a wrong assumption.

Used this way, the free plan is a prototyping tool, not a production one. The zap gets built to confirm the trigger, watched for a day or two, then either torn down or rebuilt properly on a tier that supports the filters and branching the real workflow needs. Treating it as a permanent home for a production order-sync workflow is where the plan starts costing more than it saves; treating it as a five-minute check before a real build is exactly what it’s for.

Where the free plan breaks first: multi-step logic

Most real ecommerce workflows aren’t single-step by nature. A new order coming into Shopify usually needs to update inventory, notify a fulfilment channel, and maybe tag the customer in your email platform: three actions from one trigger, not one. On Zapier’s free plan, that’s three separate zaps you’d have to string together manually, each one polling independently, each one a separate point where the chain can break without the others knowing.

Filters make this worse. Say you only want the Slack alert to fire for orders over a certain value, or only for orders shipping internationally. A filter step evaluates that condition before the action runs, and filter steps aren’t available on the free plan at all. Without one, every order that hits the trigger runs the full action, condition or no condition, which means the “automation” either fires on everything or you’re back to checking things by hand anyway.

Paths, Zapier’s term for sending one trigger down different branches depending on the data, sit in the same paid-only bucket. A workflow that needs to route wholesale orders one way and retail orders another can’t be built as a single free zap. It has to become two or three separate zaps, each watching for a different condition using its own trigger, which is slower to build, harder to maintain, and easier to leave half-updated when a rule changes.

The polling interval changes what “automated” means

Free-tier zaps check their trigger app on a longer interval than paid tiers do. That’s true across most workflow tools with a tiered free plan, and Zapier is no exception. The exact interval is published on Zapier’s pricing and help pages and is worth confirming there, since it has moved before and will likely move again.

What matters operationally is what a slower check interval does to an order workflow. A new order placed at 2:14pm might not trigger its zap until well past 2:20pm on the free tier. For a receipt email, that delay barely registers. For a fulfilment alert that’s supposed to tell a warehouse team an order is ready to pick, or a fraud-check step that’s supposed to hold an order before it ships, several minutes of lag is the gap between the automation doing its job and the automation being a formality nobody trusts.

The practical effect is that “automated” on the free plan means “eventually automated.” Teams that build critical-path logic (anything with a real deadline attached, like same-day fulfilment cutoffs) on a free-tier polling schedule tend to find out the interval matters the first time it costs them a shipping window, not before.

What happens when you hit the task limit

Zapier’s free plan includes a fixed number of tasks each month, reset on a billing cycle rather than accumulating. Zapier states the current number on its own pricing page; it has changed over time, so treat any number quoted outside that page as a starting point to verify, not a fact to build a plan around.

What’s worth knowing regardless of the exact figure is what happens at the ceiling. Zaps don’t slow down or queue: they simply stop running for the rest of the billing period. There’s no partial service and no automatic overflow onto a paid tier unless you upgrade manually. An order-tagging zap that hits its limit on the 18th of the month goes quiet until the 1st, and nothing about the free interface pushes that fact in front of you hard enough to notice quickly. The task history shows it, if you go looking. Most operators don’t go looking until a customer or a colleague flags that something stopped happening.

Task volume and revenue tend to move together without anyone planning it that way. A brand doing a handful of orders a day rarely approaches the free plan’s ceiling. A brand doing dozens of orders a day, each one firing an order-created trigger plus whatever tags or notifications ride along with it, can burn through a monthly allowance well before the month is finished, and the zaps that stop are usually the ones tied directly to fulfilment, which is the worst place for silent failure.

Which runs are actually lost matters more than the headline “zaps stop running” suggests. Once the ceiling is hit, Zapier doesn’t queue the triggers that fire afterward and process them once the cycle resets — those events are gone. An order placed on the 19th, after the limit was hit on the 18th, never gets its tag applied, never posts its alert, never updates its row, and there’s no catch-up run on the 1st that goes back and processes what was missed. The zap resumes for new events going forward; it doesn’t reconcile the gap. For a workflow tracking something like subscription renewals or inventory sync, that gap is a set of orders that simply never got the treatment every other order got, discoverable only by someone cross-checking Shopify against whatever the zap was supposed to update.

The workarounds people try, and what they cost

Because the single-step ceiling is the real constraint, most attempts to get more out of the free plan aim at faking multi-step behaviour rather than buying it. Three show up repeatedly.

Chaining single-step zaps. Instead of one zap with a filter and two actions, the workaround is two or three separate zaps: one watches the same trigger and writes to a spreadsheet row or a lightweight database record, another polls that intermediate store and fires the next action if a condition looks right. It works, in the sense that the actions eventually happen. It also means the “workflow” now lives across multiple independent zaps with no shared error handling, each on its own polling schedule, so a failure in the middle step doesn’t stop the last one from firing on stale data. Debugging becomes a matter of checking three task histories instead of one, and nobody owns the intermediate spreadsheet as the source of truth until something in it goes wrong.

Routing through a free webhook or notification tool. A common pattern is sending the free zap’s single action to a webhook endpoint (a free tier of a tool like a webhook relay or a lightweight serverless function) that does the branching Zapier’s free plan won’t, then calls back into a second zap or another app directly. This does add real conditional logic, but it moves the maintenance burden onto a second free-tier tool with its own limits, its own outages and its own account to monitor, and it usually requires someone comfortable writing a small amount of code to stand up the webhook receiver in the first place. It’s a genuine capability gain, but it isn’t free in effort even though it’s free in dollars.

Manual replays. When a single-step zap without a filter fires on everything, including orders it shouldn’t have acted on, the workaround is often just cleaning up after it by hand: deleting the erroneous Slack message, voiding the duplicate tag, re-running the correct action manually for the order that should have been excluded. This is the cheapest-looking workaround because it uses no extra tools, but it’s also the one that scales worst — the cleanup time grows in direct proportion to order volume, which is exactly the metric a real automation is supposed to remove from a person’s plate.

None of these workarounds are free once time is counted. They trade a subscription cost for a standing maintenance cost that usually falls on whoever set the zap up in the first place, and that person is rarely tracking the hours against what a paid tier, or a purpose-built platform, would have cost instead.

The hidden costs the pricing page doesn’t show

None of the free plan’s limits show up as a dollar figure anywhere, which is exactly why they’re easy to underprice. The published cost is zero. The actual cost shows up as time spent working around what the plan can’t do, and as the orders that slip through while nobody’s watching.

Three places this cost tends to land, in order of how often they show up:

• Manual reconciliation. When a workflow that should be one conditional zap has to be built as three or four separate single-step zaps to fake branching, someone has to keep them in sync by hand whenever a rule changes: a new SKU, a new shipping threshold, a new tag. That’s ongoing maintenance time that a paid plan’s filter and path steps would have removed at the point of building the zap, not after.
• Missed or late actions. A polling interval that’s fine for a Slack notification isn’t fine for anything tied to a shipping cutoff or a fraud check. The cost here isn’t visible until an order ships late or a bad order ships at all, at which point it’s a customer-service cost, not an automation cost, but it started as one.
• Staff time spent checking the dashboard. Because free-tier task failures don’t push a strong alert, someone has to build the habit of checking Zapier’s task history manually to catch a silent stop before it compounds. That’s a recurring task added to someone’s week specifically to cover a gap the free plan leaves open.

None of these show up on an invoice. They show up as a person’s time, or as an order that didn’t get the treatment it was supposed to, which is a harder cost to notice and a harder one to justify fixing, right up until it adds up.

The self-hosted comparison worth being honest about

A self-hosted tool is the other side of “free” worth naming plainly, because it’s the argument people reach for once they’ve hit the free plan’s limits: self-hosting an open-source workflow tool instead of paying Zapier at all. Tools in that category exist, run on a server you control, and don’t charge per task, so the task-limit problem that shuts off a free Zapier zap mid-month doesn’t apply to them in the same way.

What they trade it for is a maintenance cost instead of a task fee. Someone has to provision and patch the server the tool runs on, keep the workflow engine itself updated, manage authentication and uptime, and be the one who gets paged when a webhook stops delivering because a dependency broke on an update nobody tested first. None of that is priced on a monthly invoice the way a Zapier plan is, which is exactly why it’s easy to undercount: a team comparing “zero dollars a month” against “twenty dollars a month” is missing the labour on the zero-dollar side of that comparison. For a team with the engineering capacity to own that maintenance as a matter of course, the trade can make sense. For most ecommerce operations, where nobody’s job description includes patching a workflow server, the honest comparison isn’t free versus paid — it’s whose time pays for the gap either way.

When an ecommerce operation outgrows the free plan

The honest answer is: workflow shape outgrows the free plan before revenue does. The first zap that needs a filter, a second action, or a faster check interval than free polling allows is the moment the free plan stops being able to do the job, not a moment tied to how many orders you’re processing.

That said, revenue and workflow complexity tend to arrive together. A brand is, plainly, well below the $3M floor this article and Pointerflow’s own services are built for. For that size of operation, the right move is picking one workflow tool (paid tier or otherwise) and configuring it properly, not stacking single-step free zaps into something that behaves like automation without the logic to back it up. That’s a tools decision, not a strategy engagement, and it doesn’t need an audit to solve.

Above that floor, $3M and up, running Shopify Plus or a comparable paid subscription platform, the workflows involved almost never fit a single-step zap. Order sync across a subscription platform, a 3PL and an email tool; conditional routing by order value, market or fulfilment channel; alerts that have to fire inside a fulfilment deadline rather than a polling window. None of it works reliably on the free tier’s shape, whatever the task allowance says. That’s the point at which the question stops being “which Zapier plan” and starts being whether a connector tool, at any tier, is the right architecture at all, or whether the workflow needs something built to handle conditions and failure states as a first-class part of the design rather than a bolt-on filter step.

The real question is workflow design, not plan tier

A single-step, slow-polling automation is a reasonable way to test whether a workflow is worth building at all. It’s a poor way to run fulfilment, order routing or anything with a deadline once the business depends on it working every time, not most of the time. Zapier’s paid tiers add the filters, paths and faster polling the free plan is missing. Check Zapier’s own pricing page for what each tier includes, since that detail changes, but for an operation past the free plan’s shape, the underlying question is whether a general connector tool, however configured, is the right way to run conditional, deadline-bound logic in the first place. That’s an AI agents and automation problem, not a plan-selection one, and it’s the kind of problem Pointerflow’s AI agents work addresses directly: automations designed around what actually breaks at volume, not retrofitted onto a tool built for a single trigger and a single action.