A stopped automation looks exactly like a quiet week
Your automation tools are loud about errors. Zapier emails you the moment one happens, and switches an automation off once it fails almost every single time. So the failures that reach your customers are the ones that never register as failures at all: the automation that stopped running, the one that wrote a blank, the one that ran twice. None of those raise a hand. Here is how to catch them.
ChatGPTSame prompt, 2 AI models — swipe to compare. Showing 1 of 2.
Made with ChatGPT (ChatGPT Images 2.0 (gpt-image-2))view prompthide prompt
Create an editorial magazine illustration in a hand-painted style with visible soft brushstrokes and subtle oil-painting texture. NOT photoreal, NOT a 3D render. Palette: cool slate-navy and warm cream with selective deep cobalt blue accents and a single bold red accent used as a deliberate callout, cinematic 16:9 widescreen. Composition: a long empty conveyor belt of pale stone and dark brass running the length of a calm deserted workshop, the belt surface entirely bare and softly worn, a fine layer of undisturbed dust settled along one edge, one small round cobalt glass indicator lamp still glowing steadily on the belt housing, an empty open collecting vessel waiting at the far end, one single small red object lying forgotten on the floor beside the belt, cool directional light raking across the length, a quiet sense of faithful machinery carrying nothing at all. No people, no readable text, no letterforms, no numbers, no signage, no logos.
HERO for article-22 (LCP), owner web-lane render. The machine has to read as WORKING and in good order, because the article's whole point is that a stopped automation and a quiet week look identical. That killed the entire SDXL lane at review (all four rendered a derelict rusting trough in a wasteland, which argues the opposite of the piece). This ChatGPT take won over the local Flux hero originally shipped (seed 2204, kept as the gallery's second slide): it lands the actual brand palette — a lit cobalt indicator lamp for the cobalt accent, one red marble for the callout — where the Flux take ran warm/olive, and it's cleanly text-free (verified: no wall placard, unlike Flux seed 2202). Must equal featured_image_url; first key in the gallery.
Zapier will switch one of your automations off once it errors 95% of the time it runs, and only after it has run more than twenty times in the past week. That is a reasonable threshold for a company running a few hundred million of these things. Below it, the automation stays on.
Zapier turns an automation off after it errors 95% of the time it runsSit with what that means for one business. Something that fails half the time is, by that measure, working fine.
And that is the generous case, because at least a failure is an event. It gets counted. Zapier will email you about it immediately, every time, without you configuring anything, because that is the default setting.
The ones that hurt you never produce an event at all.
The automation stops running, and nothing errors
An error notification needs an error. An error needs a run. Follow that backwards and you get the whole problem: an automation that has stopped triggering generates no runs, so no errors, so no emails, so no alarm anywhere in the system.
It is not hiding the failure from you. There is no failure to report. As far as the tool is concerned, nothing happened, which is exactly what it would report on a genuinely slow week.
An automation that has stopped running looks exactly like an automation with nothing to do.
This happens more mundanely than people expect. Somebody at a software company changes something on a Tuesday and the trigger stops matching. A password change or an expired login quietly drops the connection. Somebody turns an automation off to test something and never turns it back on. Or you hit the ceiling on your plan, at which point Zapier holds actions across every automation in the account until the next billing cycle.
Notice that only some of those are anybody's fault, and none of them make a sound.
Sets off the alarm
- A step runs and returns an error
- The same step errors on nearly every run for a week
- A connected account needs reconnecting
Sets off nothing
- The trigger stops firing, so nothing runs at all
- It runs and writes an empty field
- It runs twice and creates the record twice
- It fails a third of the time, forever
It runs, and writes the wrong thing
The second failure mode is worse, because it produces a success. Somebody renames a field on one side, and the automation keeps firing on schedule and writes a blank into the other side. Every run goes green. Your customer list slowly fills with records missing the phone number.
Nothing in that chain is broken in a way software can detect. The trigger triggered, the step ran, the record was created. A tool that moves data between two apps has no opinion about whether the data was any good, and asking it to have one is asking it to understand your business.
The third mode is the same idea pointing the other way: it runs twice and you get two of everything. We spent a whole article on what that costs you when it lands in your books, so it is enough to say here that a double is also a success, twice.
The pattern behind all three: your tools can tell you a step failed. They cannot tell you the result was wrong, and they cannot tell you about work that never happened.
The check is the thing you are missing
The fix is not a better platform. If your automations are mostly working, keep them. Moving everything to a new tool buys you a fresh set of quirks and the identical blind spot.
What you are missing is a check: something that confirms the work actually happened, and happened correctly, without relying on the tool that did the work to grade itself.
At the smallest scale that check is a person and a calendar reminder.
Count both sides over the same window. Forty-one people filled in the form last week. Are there forty-one new rows in the customer list? That single comparison catches all three failure modes at once, which no amount of staring at the automation history will do, because the history can only show you the runs that happened.
Made with ChatGPT (ChatGPT Images 2.0 (gpt-image-2))view prompthide prompt
Create an editorial magazine illustration in a hand-painted style with visible soft brushstrokes and subtle oil-painting texture. NOT photoreal, NOT a 3D render. Palette: cool slate-navy and warm cream with selective deep cobalt blue accents and a single bold red accent as a deliberate callout, cinematic 16:9 widescreen. Composition: a slender brass balance scale standing on a calm cream surface, a shallow cobalt glass vessel resting on each of its two pans, the left vessel brimming with small smooth pale stones and the right vessel holding only a few, the beam tilted clearly and honestly out of level, one small red stone among those on the light side, soft warm directional light, a quiet sense of two things being compared carefully against each other. No people, no readable text, no letterforms, no numbers, no markings, no signage, no logos.
MID for article-22, owner web-lane render, sits at the 'count both sides' section. The balance is the method in one object: two counts from the same window compared against each other, which is exactly what an automation cannot do for itself. Replaces the local Flux mid originally shipped, whose beam rendered near level (the mismatch had to be carried by the bowl contents alone). This ChatGPT take gets the beam tilted honestly out of level AND keeps the cobalt-bowl / red-stone palette, so the 'these don't agree' read is immediate.
Above a certain size, that check has to run on its own. Something that expects work to happen and complains when it sees none. The rule to hold onto is that no errors does not mean nothing is wrong: you want proof of work completed, not the absence of complaints.
Not everything needs this. If an automation moves something you would notice missing by lunchtime, your business is already the check, and adding a second one is theatre. The ones that need watching are the quiet ones: the automations feeding a number somebody trusts, where nobody is waiting on the result and nothing looks wrong until a decision has been made on it.
It's the same story as the spreadsheet that had been quietly wrong for a year. A number gets believed because it appeared where numbers appear. Automating the work does not remove that risk. It removes the person who used to trip over it.
Four or more means your automations are supervised, which puts you ahead of most. Look at the ones you couldn't tick and start with whichever touches money.
Start with one automation. The one that would embarrass you in front of a customer if it had been dead since March.
Count both sides. Then decide whether you knew the answer before you counted.
If you've got a handful of automations running and nobody's sure which ones are still doing their job, tell us what they're meant to be doing and we'll tell you which ones are worth putting a check on. Some of them won't be.
Cheers, from the boring side of the business,
P.S. This question gets much sharper the moment somebody tries to sell you an AI agent that runs on top of all this. That one's coming.
Want help applying this to your business? Start a no-pressure conversation →
Frequently asked questions
- Why didn't I get an email when my automation stopped working?
- Because an error notification needs an error, and an error needs a run. Zapier emails you immediately on each error by default, so a step that fails does reach you. But an automation whose trigger stops firing never runs at all, produces no errors, and therefore sends no notifications. From the outside it looks the same as a week where nothing needed doing. That is why the check has to be for work completed, not for alerts received.
- How often does an automation actually need checking?
- Match it to what the automation touches. If it moves something you would notice missing within a day, like a lead notification that your phone stops buzzing about, the business checks it for you. If it writes to your customer list, your invoices, or anything you would make a decision on, check it monthly and count both sides. If it feeds a number somebody else relies on, it needs a check that runs on its own, because by the time a person notices, the wrong number has already been used.
- Should I replace Zapier with something more reliable?
- Usually not, and not for this reason. Every tool that moves data on a trigger has the same blind spot: it can tell you a step failed, but it cannot tell you whether the result was right, and it cannot alert you about runs that never happened. Moving to a different platform buys you a different set of quirks and the same gap. What closes the gap is a check that proves the work happened, whatever is doing the work.
- Can't I just have someone look at the automation history?
- You can, and for a handful of automations that is genuinely enough. It stops working once there are enough of them that nobody can hold the picture in their head, or once the automations run more often than a person looks. A history screen tells you what ran. It does not tell you what should have run and didn't, which is the failure you care about most.
