Recipes, Limits & Gotchas

This is the phase that saves you money and saves you a bad afternoon. The mechanics from Phases 1 and 2 work fine in a demo; the things below are what bite you once real volume flows through.

How Zapier charges you: tasks

Zapier bills on tasks. A task is one action step that successfully runs. Read that carefully, because the details decide your bill:

The trigger does not cost a task. Zapier watching your form for new entries is free; only the actions it then performs count.
Each action that runs is one task. A Zap with four actions that fires once = four tasks. The same Zap firing 100 times = 400 tasks.
A Filter that stops a Zap costs nothing for the steps that didn't run. This is why filters are your budget's best friend - guard early and you don't pay to do work you didn't want.
Formatter, Filter, and Paths steps themselves generally don't count as tasks (they're built-in utilities, not app actions), though policy can shift over time, so treat that as "cheap," not "always literally zero," and watch your usage.

The lesson: task cost scales with actions × how often the trigger fires. A noisy trigger feeding a five-action Zap burns through a plan fast. Two ways to control it: filter aggressively so most events stop early, and don't add actions you don't truly need.

Zap fires 500 times this month
  × 3 action steps that run each time
  = 1,500 tasks
(but if a filter stops 60% of runs early after step 1,
 you pay far fewer than 1,500)

Plans come with a monthly task allowance. Cross it and, depending on your plan, Zaps pause or you're moved into overage - so watch the usage meter, not only the calendar.

Polling vs instant triggers

Not every Zap reacts the instant something happens. Triggers come in two flavors:

Instant (webhook-based): the app actively pushes Zapier the moment the event occurs. Near-real-time.
Polling: Zapier checks the app on a schedule - "any new entries since last time?" The check interval depends on your plan, and on lower tiers it can be as long as every 15 minutes.

So a polling Zap can sit idle for up to that interval before it notices a new row and runs. That's not a bug; it's how polling works. If your test seemed to "do nothing," it may be waiting for the next poll - give it the interval before you panic. When you genuinely need instant reaction (a "thanks for paying" message), prefer an app whose trigger is marked Instant, or use a direct webhook.

Duplicates and missed runs

Two failure shapes show up at scale.

Duplicate runs - the Zap fires twice for one event. Causes vary: a record gets edited and re-detected, an app re-sends an event, or your own two Zaps form a loop (Zap A updates a record, which triggers Zap B, which updates it back, which re-triggers Zap A). Defenses:

Trigger on a one-time event ("new charge") rather than a re-occurring state ("charge exists") where you can.
Use a Find or Create lookup (Phase 2) so a second run updates the existing record instead of making a twin.
Add a Filter that checks a "processed?" marker and skips if it's already set.

Missed runs - the Zap doesn't fire when you expected. Usual culprits: it was switched Off, a polling interval hadn't elapsed yet, the trigger field was empty so a Filter stopped it, or the connected account's login expired and needs reconnecting.

When a Zap breaks: errors and replay

Zaps break quietly. An app changes, a required field comes through empty, or a reconnect is needed - and the Zap errors instead of completing. Where to look and what to do:

Zap History is the log of every run: which succeeded, which were filtered out, which errored. This is the first place to check when "the automation stopped working."
Turn on error alerts. Zapier can email you when a Zap starts failing. Set this up the day you build anything important; otherwise you find out when a customer does.
Replay. When you fix the cause (reconnect the account, handle the blank field), you can replay the failed runs from history so the work that got skipped still happens - you don't lose those events.
Autoreplay exists on higher plans to retry transient failures automatically.

A reliable Zap isn't one that never errors - it's one that tells you when it does and lets you recover the missed work.

A few high-value recipes

These are workhorses, not party tricks.

Lead capture, deduplicated.

TRIGGER  →  New form submission
LOOKUP   →  Find or create CRM contact by email
ACTION   →  Update contact + notify sales in Slack

Payment to bookkeeping + receipt.

TRIGGER  →  New successful Stripe charge  (Instant)
FILTER   →  Continue only if Amount > 0
ACTION   →  Add row to accounting sheet
ACTION   →  Send branded receipt email

Inbox triage.

TRIGGER  →  New labeled email (Gmail)
PATHS    →  Subject contains "invoice" → save attachment to Drive + log it
            Subject contains "refund"  → create a support ticket

Scheduled digest.

TRIGGER  →  Schedule (every weekday 8am)
ACTION   →  Read yesterday's rows from the sheet
ACTION   →  Post a summary to Slack

The short version

Tasks are actions that run, so filter early and keep action counts lean. Polling means "soon," not "instant" - pick instant triggers when timing matters. Guard against duplicates with one-time triggers and lookups. And the day you build something you'll rely on, turn on error alerts and learn where Zap History lives - because the Zaps that hurt are the ones that fail silently while you assume they're working.