Rate Limits in Zapier, Make, and n8n: What Breaks Once You Scale Past the Free Tier

A workflow that runs fine at ten executions a day behaves completely differently at a few hundred, and the difference isn't obvious until you actually hit it — none of these three platforms make their scaling ceilings prominent in the getting-started experience, because a new user testing a single workflow with a handful of sample runs will never come close to triggering them. Here's what actually happens on each platform once real volume shows up.

Why this doesn't show up in a typical comparison

Most platform comparisons, including our own earlier one at Zapier vs Make vs n8n: I rebuilt the same workflow in all three, test a workflow's logic and build experience, not its behavior under sustained real-world volume. That's a reasonable scope for a first comparison, and it's also exactly the part that doesn't predict how a workflow behaves once it's actually running your business's traffic every day for months.

Zapier: task counts, and what happens when you run out mid-month

Zapier bills by "tasks" — each action step in a Zap counts as one task, so a five-step Zap running once counts as up to five tasks against your plan's monthly allowance. The behavior that catches people off guard isn't the limit itself, it's what happens when you hit it mid-month: Zaps don't throttle gracefully or partially execute — they stop running entirely until either the next billing cycle or a plan upgrade, and any trigger events that occurred while the Zap was paused are, depending on your trigger type, not automatically replayed once tasks are available again.

// A single Zap: trigger + 4 action steps = up to 5 tasks per run
Trigger: New form submission
  → Action 1: Enrich company data      (1 task)
  → Action 2: Score the lead            (1 task)
  → Action 3: Create CRM record          (1 task)
  → Action 4: Notify rep in Slack        (1 task)
  → Action 5: Update spreadsheet log      (1 task)

A workflow that looked cheap in testing — a handful of manual test runs — can consume its monthly task allowance surprisingly fast once it's processing real volume across five action steps per run, and the fix isn't always "upgrade the plan": consolidating steps, or moving less time-sensitive actions (like the spreadsheet log) into a separate, lower-frequency batch process, reduces the task count per real-time run without losing functionality that actually needs to happen instantly.

Make: operations, and the "underestimating a loop" trap

Make counts individual "operations" rather than whole action steps, which sounds more granular and fair, and mostly is — until a workflow includes an iterator or loop over a collection of items, where each item processed inside the loop counts as its own operation. A workflow that looks like a handful of steps on the visual builder can silently multiply its actual operation count by however many items pass through a loop on a given run.

// Looks like "a few steps" on the canvas, but each item in the array
// consumes its own operation count when it hits the iterator
Trigger: New order webhook (1 op)
  → Iterator: loop over order.line_items (1 op per item, not 1 total)
    → Action: Update inventory count (1 op per item)
    → Action: Log to spreadsheet (1 op per item)

An order with 12 line items running through this scenario consumes roughly 24 operations for the loop body alone, not 2. At low order volume this is invisible. At real order volume, a scenario that "should" use a few hundred operations a day can consume several thousand, and the monthly operations allowance gets consumed far faster than a step count on the canvas would suggest. Checking a scenario's actual historical operation usage under the "History" tab, rather than estimating from the visual step count, is the only reliable way to catch this before a plan runs out mid-month.

n8n: self-hosted removes the ceiling, but moves the problem

Self-hosted n8n doesn't have a vendor-imposed task or operation ceiling at all — you're running your own server, so the limit becomes your server's actual compute and memory capacity rather than a billing tier. This sounds like a clean win, and for high-volume workflows it often is, but it moves the operational burden onto you: a workflow with a memory leak, an inefficient loop, or a node making an unexpectedly slow external API call will degrade your server's performance for every other workflow running on it, not just fail gracefully in isolation the way a SaaS platform's rate limit would.

# A real n8n memory issue: a workflow processing a large CSV import
# loaded the entire file into memory as one array before
# processing, rather than streaming it in chunks
#
# Fine for a 500-row file. On a 50,000-row file, memory
# usage spiked enough to slow down every other workflow
# sharing the same n8n instance until the import finished.

The fix for n8n at scale is less about hitting a documented limit and more about applying the same resource discipline you'd apply to any self-hosted service — monitoring memory and CPU per workflow execution, and deliberately chunking or streaming large data processing rather than loading everything into memory at once, the same principle covered from the coding side in building a sliding-window rate limiter from scratch in PHP if you're the one implementing throttling logic directly rather than relying on a platform's built-in behavior.

A side-by-side of what actually happens at the ceiling

What to check before you're already over the limit

• Look at real historical usage, not estimated usage, for any workflow that includes a loop, iterator, or per-item action — the platform's own usage dashboard is far more reliable than counting visible steps on the builder canvas.
• Separate real-time-critical actions from ones that can run in a batch. A Slack notification needs to happen instantly; a spreadsheet audit log usually doesn't, and moving it to a nightly batch step can cut real-time task/operation consumption meaningfully.
• For n8n specifically, monitor server resources per workflow, not just overall uptime — a single inefficient workflow can degrade every other workflow sharing the instance without ever throwing an explicit error.
• Build the plan-upgrade decision around actual measured growth, not a guess — if a workflow's operation count is climbing linearly with order volume, project that forward against your plan's ceiling before you're the one discovering the ceiling by hitting it mid-month.

None of this is a reason to avoid these platforms — it's a reason to check real usage numbers before scaling a workflow that was only ever tested at low volume, the same "measure before you assume" instinct that applies just as much when a workflow starts failing outright, covered in why your automation keeps silently failing.

A cost comparison that isn't just the sticker price

Comparing plan prices directly across these three platforms is misleading without accounting for what a "task" or "operation" actually costs you in practice, because the units aren't equivalent. A Zapier Zap with five action steps and a Make scenario with a twelve-item loop can process the same real-world event — one order — at wildly different unit costs against their respective plan ceilings, even if the two plans are priced similarly on paper. The only reliable way to compare real cost at your actual volume is estimating tasks-or-operations-per-real-event for each platform specifically, using your own workflow's actual shape, not a generic per-plan price comparison pulled from a pricing page.

• Count steps per real event, not per workflow. A five-step Zap processing one form submission uses five tasks; the same logic in Make, without a loop, might use five operations too — but the moment either includes a loop over a variable-length collection, the two stop being comparable at all.
• Multiply by your actual expected volume, not a round estimate — pulling real order or lead counts from the last 30 days and projecting forward is more reliable than guessing.
• Re-check after any workflow change that adds a loop or a new action step. A workflow's cost profile isn't fixed once at launch — it changes every time someone adds a step, and nobody proactively re-checks the operations math when that happens.

What we changed after finding this the hard way

The concrete change on our end wasn't switching platforms — the workflow logic itself was fine on all three, and none of this is really a platform-quality issue so much as a visibility issue. It was adding a monthly calendar reminder to check actual usage against plan ceilings for every production workflow above a certain volume threshold, rather than waiting to discover a ceiling by hitting it mid-month during a busy week, which is exactly when a paused automation does the most damage — a lead-routing Zap running out of tasks during your highest-traffic week of the month is a worse time to discover a limit than during a quiet one, and neither the platform nor your calendar will warn you which week that's going to be in advance.

Alerting before the ceiling, not after

Beyond the monthly manual check, the more durable fix was wiring a lightweight usage-polling script against each platform's own usage API, run daily, that posts a warning once consumption crosses 80% of the plan's monthly allowance projected forward at the current daily rate:

function checkUsageProjection(int $usedSoFar, int $planLimit, int $dayOfMonth, int $daysInMonth): void
{
    $dailyRate = $usedSoFar / max($dayOfMonth, 1);
    $projectedTotal = $dailyRate * $daysInMonth;

    if ($projectedTotal > $planLimit * 0.8) {
        Notification::route('slack', config('services.slack.ops_channel'))
            ->notify(new AutomationUsageWarning($projectedTotal, $planLimit));
    }
}

Projecting forward from the current daily rate, rather than just checking the raw total-so-far against the limit, catches the problem earlier in the month — a workflow on pace to blow past its ceiling by day 25 is visible from this projection as early as day 10, which leaves enough runway to either trim usage or upgrade the plan before anything actually stops running, rather than finding out only once the ceiling has already been hit.