How to Fix Weird Automation Fails That Waste Days
1. Webhooks Only Triggering Once Despite Multiple Matching Events
Set up a webhook expecting it to fire on every new row in a table? Yeah, me too. And it worked—in staging. But the moment I moved it to prod and fed it real data, it just… stopped. Or rather, it fired once, and then ignored the next 6 incoming rows, all seemingly identical in structure.
This one comes down to how platforms like Airtable and Notion batch updates—or worse, deduplicate them behind the scenes. Airtable’s automation panel has zero visibility on webhook history unless you dig into log exports. Notion is even worse unless you’re using a proxy with logging. Turns out, if a webhook sends the same payload twice in under a few seconds, some platforms will rate-limit or suppress duplicate calls assuming it’s a loop. It’s not. I just had six leads at the same time.
I’ve ended up tossing a timestamp key into my payload manually, even if the value was just JS’s Date.now(). That was enough entropy to convince Zapier and n8n the call needed to process separately. That tiny tweak saved me from doing a dead-eyed CSV export every Friday night.
2. GPT Prompts Give Different Results On Identical Inputs
This still haunts me. I had an OpenAI call embedded inside a Make.com workflow that summarized ticket notes from Intercom into Slack TLDRs. Worked beautifully through my tests. But when I ran it live on three different Majestic plumbing tickets, it output: one gem, one totally off-topic horoscope, and one blank. Blank. The payload was fine. The function ran. Output was a single whitespace character.
The trifecta at play was:
- Make.com defaulted to GPT-4, which changed silently after an API update
- The prompt passed in unpredictable order when using bracketed variables (it reordered fields alphabetically)
- The API key had HIT its new per-minute rate cap because of another unrelated flow
I shifted the prompt to string interpolation—literally just building a raw block of text with all the fields in the correct order—and the hallucinations stopped. Not completely, but there was coherence again. The rate-limiting ghost still reappears sometimes, so I added a retry block with an exponential delay. Watching an AI trip over itself because the input structure changed order felt like teaching my dog a new trick, only for it to unlearn the old one.
3. Zapier Filters That Run But Still Let Triggers Through
This one is subtle and insane: In Zapier, you can add a filter to block records that don’t meet your condition. Let’s say, only continue if “Status” equals “Approved”. That part’s fine. But what Zapier doesn’t warn you about is how certain text fields behave if they include intentional or invisible whitespace.
Literally had an Airtable view where “Approved” looked like “Approved” to the naked eye—but in the incoming JSON, there was a trailing space. One space. Just a \u0020. So the filter condition Status = Approved silently failed. Except Zapier doesn’t always surface failed filters unless you scroll down past four logs and click the “Zap History” details. Meanwhile, the trigger still ran, only to stop later and clog the logs.
The workaround? Use a custom code step to normalize that input, or use a Contains filter instead. Even better, pipe it through Formatter → Text → Trim Whitespace before your filter. That’s what ended up stabilizing mine. Shouldn’t have to. But, here we are.
4. Airtable Automations Fire Twice When Using Linked Records
Linked records in Airtable are nice—until they aren’t. I had a simple automation: when a form submission created a new row in the Leads table, I wanted to copy details into a separate Campaign Participants table. Easy.
But when linking a new Form entry to an existing Campaign record, Airtable sees a change on BOTH sides of the relationship. Which triggered the automation two times—once for the Form entry, once for the Campaign. So I got double data, and worse, sometimes even recursion if the script looped backward.
What finally saved it: an OR condition trigger with a timestamp check. If the Created Time was more than 1 minute older than the Last Modified Time, I bailed. Airtable automations can’t debounce gracefully, so using timing hacks is the only defense when linked records go wild. There’s something deeply annoying about relying on seconds to stabilize an entire workflow, but this is exactly where we live.
5. Make Com Scenario That Fails Silently When Using Array Aggregator
I was building what looked like a straightforward Make.com scenario: pull new rows from a Google Sheet, bundle them into an array, send that to Slack in a single message. Except half the time—nothing showed up. No error. No Slack webhook. No history past the aggregator step. I actually thought Slack was rate-limiting me.
Nope. It was Make being weird with spacing inside the aggregator. If one of the array values was null or empty, the entire array failed silently without crashing the scenario. It just skipped forward. And unless you explicitly log the output of the aggregator step, you’ll never see it disappear.
The fix? Add a filter before the aggregator to only include items where the field existed and had more than zero characters. Also, explicitly set fallback values using Replace Missing in a Tools module before aggregating. Asking Make to handle optional fields in an email-style message body will eventually produce a ghost step that “ran” but did nothing. The click path to figure this out is 12 steps deep.
6. Google Sheets Trigger Stops If Data Validation Breaks Down
This one doesn’t even throw an error. Had a team member edit a cell under a drop-down column, but they pasted in the value instead of selecting—from a list of country codes, no less. So technically it matched—but not exactly. So Google Sheets let it stay. My Zap that filtered for “only when Country is one of these” just froze. No new leads got forwarded to Salesforce, and we only noticed when the sales rep angrily asked why a client hadn’t been contacted in a week.
The race condition here was that Google Sheets triggers are shaky if a cell is pasted with formatting that violates the original column constraint. Sheets won’t alert Zapier, it just ignores it. And Zapier will call Google Sheets, think nothing changed due to the mismatch, and keep going like everything’s fine.
I ended up forcing a hidden calculated column that re-validated entries with strict REGEXMATCH rules—then used that new column as the filter step in Zapier. Yes, I had to regex country codes like some kind of digital bureaucrat. But it didn’t fail again after that.
7. Conditions Fail In Obsidian If Templates Create Unsaved Notes
This was deep nerd territory: I had an Obsidian daily note template that ran Dataview queries and pre-pasted some YAML metadata via Templater. I used that to track daily tasks and generate a weekly review with rollups. The failure showed up when I auto-created a note in Obsidian Mobile, but forgot to open it that day. No edits, no manual save.
The problem? That note never got rendered by the Templater plugin until I opened it. So my Dataview query looking for status: open found nothing. Didn’t even show that day existed. My weekly review script—which runs via a local script that scrapes the vault—completely skipped it. Because the YAML technically wasn’t there. I only figured this part out when I opened the note a week later and saw the {{unfinished}} template placeholders still sitting there.
The fix is ugly, but works: a cron job that force-opens-and-saves today’s note at midnight server time using a keyboard automation via AutoHotKey. Or, use the Templater JS API to pre-render the daily note during note creation instead of on opening. Hidden triggers based on human interaction like “actually opening the file” are pure pain in automation.
8. Unexpected Capitalization Breaks Notion Filters In Zapier Steps
Again with the spacing and casing stuff. Notion fields are case-sensitive when accessed via the Zapier Notion integration. I had a filtered database view based on a “Project Stage” field. There were values like “In Progress”, “Finalized”, and so on. The automation was supposed to trigger updates when a card entered “Finalized”. Obvious, right?
Not if someone accidentally typed “finalized” with a lowercase f. Which they did, because they created a new card on mobile and typed it manually. Since Notion doesn’t enforce select options on mobile input (this is real, and bad), now the field had a lowercase variant. To humans it looks the same. Zapier? Nope. Filters failed. Card ignored.
I had to switch from exact match filters to a code step using toLowerCase() and normalize the input. Also ran a cleanup script to patch in any rogue values periodically. This should’ve been enforced by Notion. But automation has no sense of these little things humans do wrong 2% of the time—and that’s where everything breaks.