When a working zap just decides to die
You know that feeling where a workflow has been humming along for days and then suddenly just explodes for no reason? That was me yesterday with a Zapier automation that was moving leads from Typeform into Google Sheets and then pinging Slack. The form submissions still came in fine, the sheet updated like a soldier, but Slack? Nothing. Not even an error. Just dead air.
So I opened up the Zap editor, and the trigger was fine, the sheet step showed green checkmarks on recent runs, but the Slack step was totally skipped. Zapier didn’t yell, didn’t log a warning. It just… gave up. That’s where frustration starts because you don’t have a red X to chase. You have literal silence.
The first useful thing I did was flip over to Zap history and manually replay one of the failed tasks. On replay, suddenly Slack went through perfectly, so that proved there was nothing wrong with the credentials or channel permissions. The inconsistent part is what kills you — if it fails the same way every time, at least you have something solid to debug. Here, it was working only when I forced it, not on its own.
One trick I’ve picked up: always add a test filter step before the action that’s misbehaving. In my case, I set up a Zapier filter to pass only if the “email” field from Typeform wasn’t blank. Weirdly, that fixed the randomness. Turns out some troll submitted just the word “hi” with nothing else, and Slack didn’t know what to do with my formatting. Without that filter, Zapier still claimed “success” for the trigger but ignored the empty payload later. → Lesson learned, junk submissions can sometimes break downstream logic silently. 🙂
Making sense of task histories that lie
Zapier’s task history screen looks helpful until you actually rely on it. The step-by-step view often says “success” even when the step never fired. For example, I’ve seen rows where the action clearly wasn’t performed, but it lights up green anyway. It’s like the app equivalent of someone saying “yep, totally did that” when you know they didn’t.
The real move here: click into the data details side panel. The little grey dropdown that expands shows the exact JSON payload Zapier tried to send. If you scroll down and see that Slack “text” field is empty or truncated, bingo. The UI said green, but the body told the truth. If you’re working with Google Sheets steps, the same thing applies. Rows may look written in history, but the “row ID” field will expose if no data attached.
It feels overly nerdy but copy that JSON blob into your notes because diffing between a successful run and a failed one often shows tiny differences. A missing field name, extra line break, misplaced quote mark — these are the culprits.
Pro tip I fell into by accident: tasks that say “success” but are skipped will not consume your task count. At first I thought I was losing tasks into a void, but the counters don’t go down unless the step actually fires. Still maddening though.
Weird zap loops and double triggers
This one ruins mornings quickly. Picture this: you set up a zap so every new row in Google Sheets sends a Gmail notification. Great. But then Gmail triggers another zap pushing content back into that same sheet. Suddenly, you’ve built a monster that keeps triggering itself endlessly until Zapier suspends your account. 😛
The fix is so dumb yet easy to forget: add a filter that says “Only continue if column X contains something unique” or use “Zapier Delay” to give yourself enough time to cancel before it spirals. Another trick is to maintain a helper column in Sheets, literally just called “Zapped?” with a yes or blank. First step in the zap writes “Yes” to that column so the trigger knows not to touch it again. Super simple, but if you forget it, you’ll watch your inbox explode with two hundred duplicate emails and you’ll be fighting both Gmail and Zapier throttles at once.
AWS once ate a whole day from me when a webhook fired four times per submission just because of retry logic. If you’re pulling from webhooks, remember that POST requests can and often do repeat when the upstream app doesn’t hear back “200 OK” fast enough. Zapier sees every copy. So anytime you see duplicate records, check whether it’s not Zapier’s fault at all but actually the sender retrying.
Fixing time zones that ruin schedules
Oh the time zone fun. I live on the east coast, but half my apps default to UTC or west coast time. Zapier doesn’t exactly warn you that a “7 AM” schedule is relative to wherever the zap thinks it lives. I once made a zap that sent a customer reminder email “1 day before” a booking. Instead, they got it more than halfway through the actual booking day because the zap clocked in UTC.
My solution is brute force: always add a Format Date step and manually convert into your local timezone every single time. Don’t trust the app’s default. In Formatter, you can specify “America New York” or “America Los Angeles” and rest easier. It doesn’t matter if you think it’s redundant, do it anyway. Also, write your own sanity check row into Google Sheets with the date the zap THINKS it’s working with. That way you don’t just trust invisible conversions.
I once built a table like this in Sheets:
| Original Trigger Date | After Formatter | After Conversion |
|———————–|—————–|—————–|
| 2023 04 12 15 00 UTC | 2023 04 12 11 00 EDT | 2023 04 12 11 00 Local |
That tiny exercise stopped me from misfiring meeting reminders in the middle of the night. ¯\_(ツ)_/¯
Auth tokens that break randomly
Here’s one that will drive you nuts. Monday.com tokens in my setup love to expire silently. The zap editor still claims the account is connected, but mid run you’ll see failed logs that say “Invalid API token.” What’s happening is Zapier caches old tokens and doesn’t always refresh when the service rotates them. So a working zap yesterday just fails spectacularly today.
Honestly the fastest fix is annoyingly manual. Go into Connected Accounts, fully remove the app, re add it, and paste the fresh token again. Then you have to go into ANY zap using that connection and update each step so it recognizes the new auth. Miss one, and you’ll see phantom failures again.
There’s no way around it except to keep a note with all your current tokens and the dates they expire. Some services do refresh tokens automatically, but if not, you’ll babysit them. If you’re not sure, test it by running a zap step directly in the editor — when it says “We had trouble connecting,” you’re already at the point of breakage.
Formatters that mess up text badly
Zapier Formatter is great until it randomly strips spaces or line breaks. I had a zap sending long customer notes into Airtable, but anytime the text had multiple paragraphs, Formatter smashed it all into one long unreadable line. Looks fine in preview, looks trash in Airtable.
The trick was toggling between Plain Text and HTML modes in Formatter. Zapier sometimes treats line breaks differently across apps. By converting into HTML and adding a
manually inside, it preserved the spacing. Another time I had to instead insert “\n” in the text template so Slack respected the breaks. None of this is obvious until you test live data, because the preview step often lies.
A little hack table I keep for myself:
| Destination App | Preserves Line Breaks | Needs Fix |
|—————–|————————|———–|
| Slack | \n required | Yes |
| Airtable Long Text | Passes fine if HTML | Sometimes |
| Email body via Gmail | Defaults ok | Rarely |
Without this cheat sheet I’d still be wondering why my customers got emails that look like one solid brick of text. 😅
Unexpected failures from rate limits
The sneakiest failures aren’t even bugs, they’re throttling. Google Maps API, Slack, and Gmail all have hidden ceilings for how many actions you can send per minute. Zapier doesn’t warn you. Instead you get vague “timeout” errors. I once fired a zap that blasted thirty Slack messages at once into different channels, and Slack flat out ignored half of them. No error inside Zapier, no notice, just… gone.
What I do now is insert a Zapier Delay step of one minute and make it “spread out” the messages so they drip feed one at a time. It slows down the zap but at least everything delivers. Another lifesaver is Zapier’s built in “Looping by Zapier” tool, which trickles array data instead of sending all rows in parallel. If you’ve ever seen missing rows when bulk sending, that’s the cure.
Funny enough, when testing small, everything looks perfect — only the live run with 100 records shows the holes. So always stress test with dummy data in groups of at least ten to see if your app still holds.
When nothing fixes it except rebuilding
Sometimes I just nuke the whole zap and restart. As painful as it sounds, duplicating a broken zap into a fresh one occasionally clears weird corruption. I had a Trello integration that refused to update card descriptions. After an hour of debugging, I cloned the zap, readded the Trello step from scratch, and like magic it worked again. No explanation. No visible difference. Just Zapier being Zapier.
If you’re hitting that wall, stop wasting time hunting invisible ghosts. Duplicate, re connect accounts, re map the fields by hand. I know it’s tedious, but it has saved me more than once. And yes, sometimes it stops working again a week later — but at least you know the crazy fix is always there if you rebuild and keep going from scratch.