Common Zapier Errors That Make You Want To Scream
Every time I update a spreadsheet trigger in Zapier, something breaks six hours later when I need it most. It’ll run fine at first, then suddenly skip data, fire early, or—my absolute favorite—just not trigger at all. That particular disaster pointed me toward the following errors I see startups hit constantly, especially when building automations under pressure.
## 1. Formatter by Zapier keeps breaking date fields after updates
There’s this subtle, cruel issue: if your trigger step outputs a date in one format (say, ISO 8601 like “2024-01-15T13:45:00Z”) and you build your Formatter step around that, you assume it’ll stay the same. But one day, your source app (like Airtable) suddenly starts sending US-style “01/15/2024, 1:45 PM” — without warning — and the Formatter fails silently. Your Zap completes, but your timestamp fields show up blank in Notion, because the Formatter couldn’t parse them.
Real case: In Monday.com, I was pulling a timestamp from an activity log and formatting it. Worked fine for weeks. Then a UX update changed how their API returned date strings — not logged anywhere in changelogs — and my automation silently stopped populating the item’s Created field. I only noticed because someone asked why new clients weren’t showing arrival times.
One workaround is to double the Formatter steps — parse with “Guess format” first, then reformat explicitly. But that’s a sloppy patch and still fails about 30% of the time when JSON structures change dynamically. If you’ve got control over the source app, setting up a fixed date output (like a formula field in Airtable with DATETIME_FORMAT) avoids the problem. Otherwise, you’re crossing your fingers every time an app updates.
## 2. Webhooks sent twice from forms built in Tally
I love Tally — it’s quick to launch and has built-in Zapier support. But there’s this bizarre thing where Tally sometimes double-fires the webhook when a form is submitted, especially if the user triggers redirect behavior or browser reloads immediately after submission. What you end up with: two Create Row steps in Google Sheets for the same person, or two onboarding emails going out via MailerLite (yep, that happened 😅).
What’s worse is when the first webhook comes through with incomplete data, and the second one has the full form. Because Zapier runs the first one right away, you send someone a broken welcome packet. Cue awkward apology emails.
The dejank fix here was adding a deduplication step through Storage by Zapier — checking if the same email showed up in the last few minutes using a key. Or, if you want to keep things in Sheets, add a filter that checks if a row for that email already exists before continuing. Not ideal for large-scale reliability, but it’s saved us from sending duplicate Slack alerts at 2am.
## 3. Search steps returning false positives or empty fields
Zapier’s Find steps — like “Find Contact in HubSpot” or “Find Row in Google Sheets” — seem straightforward, but they misfire more than I’d like to admit. Sometimes they return data from the wrong column, especially if the source app sneaks in hidden rows or trailing whitespaces.
An actual nightmare: I had a Zap looking up client records in a shared sheet submitted by sales reps. The Find Row step looked up by email address. Problem was, some rows had extra spaces at the end of email addresses, like “lucy@company.com␣␣” (not visible unless you view the raw cell), and the search failed silently. Or worse — it found the wrong row because the email matched partially against another one in an accidental way.
Here’s how I salvaged that Zap:
1. Added a Formatter step to trim whitespace from emails before searching
2. Lowercased both the search input and the spreadsheet column (Sheets formulas helped — something like =LOWER(TRIM(A2)))
3. Used the built-in error handling to route failed matches to a Slack alert
That third one helped me catch bad data while the Zap ran instead of after everything broke.
## 4. Existing Zap triggers silently stop working in Airtable
This one is quieter and more dangerous. I’ve had Airtable trigger steps just stop activating — not fail, just never fire again. Didn’t know until someone pinged me complaining their workflow didn’t launch. Turns out if you change a view’s filters, even slightly, it can invalidate the Zap trigger that’s relying on “New Record in View.” But Zapier doesn’t warn you.
A real scenario: I had a view that filtered for “Status is Ready.” Then someone added a second filter for “Checklist Complete is true,” and boom — nothing triggered anymore. The Zap sat quietly for three days until we noticed revenue emails weren’t going out. No errors, no alerts, just… nothing.
I now log Slack alerts every 12 hours confirming the Zap has triggered at least once. No triggers? Red flag goes up. Also, I document all view filters in shared Notion pages, where anyone modifying Airtable has to update what’s changed. Only works if your team’s disciplined — but it’s still better than being ghosted by a Zap.
## 5. Unexpected behavior from Zapier filters after field updates
Zapier’s filter steps are deceptively fragile. They don’t always revalidate when upstream fields change. If you start filtering based on a dropdown field from Airtable (like Stage = “Qualified”), and then later someone renames that dropdown option to “Qualified Lead” — your Filter step doesn’t update. The Zap starts failing quietly. Again.
I was helping a client connect their CRM to a lead scoring system. They were using filters to only proceed if Stage = “Cold Lead.” At some point, their team restructured the naming — changed it to “Lead Stage: Cold” — and never told me. The Zap didn’t match anymore, but it also didn’t fail. Just… stopped routing.
I now use Formatter steps more proactively — pulling values and doing lowercase contains checks instead of strict matching. So instead of:
> Stage exactly matches “Cold Lead”
I use:
> Lowercase stage contains “cold”
Clunkier? Yes. Safer across human chaos? Absolutely.
Also worth noting: even minor edits in an Airtable base can cause fields to shift their internal IDs. So if a field is deleted and re-added — with the same label — Zapier might treat it as an entirely different field behind the scenes. Your filter will keep pointing to a ghost field that doesn’t live in the base anymore.
¯\_(ツ)_/¯ Basically, if something changes and your Zap seems quieter than usual, don’t just wait for someone to complain. Go double check the filters before it ruins your Sunday pizza.