Why the zap stopped working this morning
When I first sat down with my coffee, I noticed one of my Zaps was dead silent. Normally it fires anytime a new Google Form response comes in, then pushes it into Airtable, then Slack. But today nothing. No Slack ping, nothing in the Airtable table. My first reaction was that I forgot to turn it back on. I opened Zapier and saw the toggle was green. Then I looked at the task history. Totally empty. Weird. I did not change the trigger. It was set to Google Forms new response. But when I clicked into the Zap settings, I noticed the connected account had a little orange exclamation icon. Apparently, Google had randomly disconnected the integration overnight. This happens more often than Iād like to admit š
So the first fix was just reconnecting the account. I clicked manage connected accounts, chose Google, reauthenticated, and immediately the zap test pulled up the latest form entry. Slack notification fired fine. Airtable row created correctly. All from a single disconnection that gave me zero alert.
Testing steps that actually worked
Whenever I debug these things I like to keep a scratch Zap running. Basically I build a spare Zap with the same first trigger but instead of pushing into real destinations, it just spits into Google Sheets. That way I can see exactly what payload the trigger is dumping. When I ran that test today, I saw the form ID was showing correctly but the answers came across with cryptic field names. For example instead of Question One it came out like Entry12345. That ruined my field mapping downstream in Airtable. Instead of filling in the actual email address, it just put \”Entry12345\” as a literal string. Took me 15 minutes of flipping back and forth between the Airtable field settings and the Zap payload preview to realize the field names had shifted. Google Forms sometimes renames its internal field IDs when you duplicate or edit a question. So I had to re map all the fields in Zapier manually. Pretty annoying but at least consistent once done.
Weird bug that doubles the webhook
Later this afternoon I had another case with a webhook action. I set up a Zap that receives from a webhook and then posts to Slack. For some reason, every payload was showing up twice. Slack messages came doubled like an echo. I checked the webhook catcher in Zapier and indeed the task history showed two tasks triggered within the exact same second. I thought maybe the sender app was firing twice. To test it I opened a simple curl command line:
“`
curl -X POST -H “Content-Type: application/json” -d ‘{“hello”:”world”}’ https://hooks.zapier.com/blahblah
“`
Only one request was sent. Yet Zapier stored it twice. The only way I got around it was by adding a filter step that looked at a unique timestamp. If a duplicate came in within the same second, drop it. Not elegant but saved my sanity.
Adding logs directly into Google Sheets
A trick that helps when I keep losing track of what happened is to log everything into a simple Google Sheet before the real action runs. Like I will make the Zap trigger, then step one logs a row into Google Sheets with the payload, timestamp, and Zap run ID. Only after that do I push into Airtable, Slack, or whatever. The sheet becomes a cheap little version of a log file. Sometimes you see nothing for hours, and then two rows pop in at once. That usually means the upstream trigger app had a delay. Helpful when I am chasing ghosts and not sure if the bug is in my Zapier build or in the sender app :P.
How I juggle too many open Zaps
I will admit I probably have twenty different Zaps half done right now. Some are turned off with warning triangles, others are paused on step two waiting for sample data. The best way I make sense of it is naming them extremely bluntly. Like I will call one \”Test Slack donotdelete\” or \”GformsToAirBaseCheckIDs\”. Without those labels, I would have zero idea what each Zap is supposed to do after a week. I also learned to always include a \”dummy step\” at the end that just sends all the data into a catch all Google Sheet. That way, even if everything else breaks, I still have proof the Zap actually fired. Makes me less paranoid when I stop checking Slack every two minutes.
Noticing small interface changes that cause pain
Something nobody tells beginners is that Zapier will quietly update the editor without warning. Last month, I logged in and saw the test button was hidden behind a dropdown. For fifteen minutes I thought my Zaps could not be tested anymore. Another time, the \”Continue\” button on a step turned gray even though I filled everything in. Clicking it did nothing. Turned out I had to reselect the account from the dropdown even though it was already shown. Those UI quirks eat more time than the actual logic. It feels like fighting the platform instead of automating with it :).
Small tools that actually help troubleshooting
I keep two browser extensions pinned just for this debugging. One is the JSON Viewer so when webhook payloads fly in, I can expand them easily instead of staring at one giant wall of text. The second is a timestamp converter because the epoch times in Zapier logs are useless on their own. With those two little helpers, I can glance at payloads a lot faster. And honestly I end up spending more time in the Google Sheets logs I set up than in Zapier itself. Sheets never lies, it just shows what actually arrived. If anyone is starting out, trust the logs you make for yourself more than the Zapier task view.
When nothing else works just rebuild
Every once in a while I really cannot figure out what went wrong. In those cases I stop, duplicate the Zap, and rebuild the steps from scratch. Strangely often it just works again. Like Zapier has some hidden corruption issue. This happened last week with a Mailchimp integration. The trigger would never pass the test even though the account was connected. I duplicated the Zap, remapped the fields, and suddenly the test worked fine. Same fields, same account. The only difference was the Zap ID. Which makes me think the problem is purely internal to Zapier. It is frustrating, but after a while you just accept that rebuilding from scratch is sometimes faster than chasing a phantom bug.
Where to look if the bug persists
If I get truly stuck, I usually search around the Zapier community forum or the Airtable community directly. The Zapier main site also has basic docs but they rarely cover the weird edge cases. I find other users posting screenshots of the exact same bug a lifesaver. Sometimes they even get acknowledgments from staff that \”yep this is a known bug we are patching next week.\” That at least saves me the time of tearing down and rebuilding. On the rare times I hit a Google workspace bug, the main Google site has announcements in their workspace updates section but you have to dig for it.