Why automations fail silently, and how to make them speak up

August 8, 202619 min read

An automation that has stopped working looks exactly like an automation with nothing to do. Both produce silence: no message, no red mark, no line in a log anybody reads. Automations fail silently because that resemblance is built into how Zapier, Make and n8n report on themselves, and not because you failed to switch something on.

One half of this is organisational: who owns the thing when it breaks, and whether that person should be you. That is one of the five tests in when not to automate a process. This piece is about the other half. Why a workflow is able to stay quiet at all, and what to build in so that silence stops being ambiguous.

Your platform reports whether a run finished. It does not report whether the run did the job you set it up to do. Those are different questions, and almost every dashboard answers only the first.

Why does a broken automation still report success?

Because "no error" and "the work is done" are separate questions, and the run status answers the first one. Zapier defines eleven run statuses. Two of the most common, Filtered and Safely halted, describe runs in which nothing happened and nothing went wrong. Both count as ordinary days on your screen.

Filtered means the conditions in a filter step were not met, so the workflow did not run any of the steps after it. Safely halted means the run purposely stopped, usually because a search found no results. Both are documented, intended behaviour. Both also describe a Monday on which a new enquiry never reached anybody's inbox.

Zapier documents the blind spot itself, in the guidance it gives to developers building integrations. An app must never return a success response when the request actually failed, because an error delivered inside a successful response "will not show up as an error in the Zap history". If the connected app misreports, the history records a success, and nothing on your screen disagrees with it.

What do the platforms do by default when a step fails?

Less than most owners assume, and in two documented cases the platform marks a failed run as a success. Make's store for failed data ships switched off. Zapier stops sending error emails as soon as an error handler runs. All of it is in the manuals, and all of it is the sensible answer to a different question than the one you are asking.

Platform	When a step fails and you have set nothing up	Retries	Where failed work is kept	Who is told
Zapier	The run stops, marked as errored	No, replay has to be switched on and needs a paid plan	Zap history, with manual replay	Email to the account owner, except when an error handler runs
Make	The run stops with an error, and repeated errors deactivate the scenario	Only when the other system asks it to slow down, or the connection drops or times out	Incomplete executions, which you have to switch on	An error email straight away, then a deactivation email if it keeps happening
n8n	The run, which n8n calls an execution, stops and is marked as failed	No, the retry setting sits on each step and has to be switched on	The execution list	Nobody, until you build an error workflow
Stripe, for contrast	Retries for up to three days with growing gaps	Yes	Delivery attempts of the last fifteen days, resendable by hand	An email saying the endpoint is failing
Shopify, for contrast	Retries up to eight times over four hours; after a day of failures it stops sending that kind of notification	Yes	Nothing, once it stops	Delivery figures you have to go and read

Make offers five error handlers and publishes the run status each one produces. Skip "prevents the scenario from stopping and marks the run as successful, even if an error occurs". Resume substitutes a value of your choosing for the output of the failed step, and also finishes green.

Make's own help page gives the example, and it repays a second read. A record with no email address is given a placeholder such as unknown@company.com, and the scenario carries on through the remaining records as normal. Make frames that placeholder as a flag for review, and logs the failed record against it. Nothing in the run insists that anybody looks.

Zapier has its own version. Error notification emails go to the account owner by default, and "Zapier will not send any error notification emails when an error handler runs". The thing that handles errors switches off the thing that told you about them. The Alerts page lists every workflow with problems in the last seven days. It is on Enterprise plans only, so a six-person clinic cannot buy its way to that dashboard.

Each of these behaviours is deliberate. The handlers exist so that one bad record does not stop a hundred good ones, which is the right trade in plenty of situations. The trade is only sound when somebody made it on purpose. And a handler that keeps the run going resolves it in favour of carrying on quietly. The email that would have told you otherwise switches itself off as a side effect of adding one.

Can a monitoring tool close the gap?

Partly. The limit is structural, and a better tool does not move it. A monitor is a second automation, exposed to the same failures as the first. A heartbeat proves only that something reported in. Whether any work got done is a separate question, and the quietest failures live in that gap.

Heartbeat monitoring works as a dead man's switch. Healthchecks.io describes its own behaviour plainly: it "keeps silent as long as pings arrive on time" and raises an alert as soon as one does not. Its guide lists what this catches, among other things: the machine being down, the timer that should have started the job not running, and the job exiting with an error. A job that runs for an abnormally long time is on the list too. All four are worth catching, and none of them is the failure that should worry you most.

The one it misses is the workflow that runs on time, reports in, and achieves nothing. A process waiting on an answer that will never come goes on saying it is alive for as long as you let it. Being alive is a claim it can make without doing any work, and progress is the only version of that claim you can check.

There is a sharper limit underneath. If a workflow never triggers, a heartbeat step living inside that workflow never runs either. A practitioner made exactly that point in Zapier's community, in a thread asking how to watch client workflows for silent failures. A monitor inside the thing it watches goes quiet at the same moment. Put it outside and it will tell you that no report arrived, though it still has no way to check that a report which did arrive was true.

The useful version measures progress: the last piece of work completed, and when. Cronitor lists this as its third kind of alert, where data sent along with the heartbeat has to pass a rule you defined in advance. That is the only one that tests what actually happened.

Which of your processes deserve this treatment, and which are fine left simple, is one of the things the process audit settles before anything is built.

What is the difference between nothing to do and nothing happened?

One is a quiet Tuesday and the other is a fault, and most systems display them identically. Any step can end three ways: it never ran, it ran and found nothing, or it ran and broke. Collapse the first two into "no error" and the failures that stay quiet longest become invisible by design.

Outcome	What appears on screen	What it means	Who fixes it
Never ran	Nothing	A schedule, trigger or condition did not fire	Whoever set up the trigger
Ran, found nothing	Nothing	The source returned an empty answer	Whoever owns the data source
Ran and broke	Usually an error	The step itself failed	Whoever built the workflow

A dental practice sends reminders three days before an appointment. On Monday nothing goes out. The schedule may not have fired at all. Or the step asked the calendar for Thursday and got an empty list back, because a field was renamed in an export last week. Or the messaging provider refused the lot. Thursday is fully booked in all three cases, and the screen looks the same in all three.

n8n is explicit about the empty case in one narrow sense. Steps that check a source on a timer count towards your quota only when they find new data. A check that comes back empty does not count as a run at all. That is a billing rule, and the documentation makes no promise about where such a check shows up afterwards. Which is the whole problem in miniature: the empty check is the cheapest event in the system and the easiest to lose.

What to require instead is a workflow that can say what it did, in the shape of "ran at 06:00, found 14 appointments, sent 14". Zero found is an event, and it needs reporting like any other. A line that says the same thing every morning becomes wallpaper within a month, which is a real cost and a much smaller one than a silence you cannot read.

Why must an empty answer never overwrite a good one?

Because an empty answer is far more often a failed question than a true zero. A system that writes back whatever the source returned will erase correct data the first time that source has a bad night. The wipe then finishes successfully, with a fresh time and date sitting on top of it.

This has happened in public, on two different platforms. On Make's community forum in September 2023, a user reported that a two-year-old scenario had begun clearing fields it was never meant to touch: "Those left empty should not be affected. And I want to stress that it did work like this all this time, we haven't changed anything." He found it by comparing two runs fifty minutes apart.

The same shape turned up on Zapier's forum in the same month. Columns deliberately left unmapped were written with empty values, destroying the formulas in them. The person who reported it worked out why: "Almost as if by not mapping the field its inputting a blank which overwrites the information already there if that makes sense." Nobody in that thread reports an error. The complaint is entirely about what appeared in the cells.

A lettings agency syncs its listings from a portal into an internal sheet every hour. One night the portal returns a valid response containing no listings. The sync does what it was told and brings the sheet into line with the source. By morning the agency has no properties on its books, two years of prices and descriptions replaced with blanks, and a note on top saying updated successfully at 04:00.

Two rules cover most of this:

Write over a good value only when the new value is actually something. Where the source returned nothing, change nothing and raise a flag.
Treat a collapse in volume as a suspicion. Four hundred rows yesterday and three today is a reason to stop and ask a person.

Both will stop you on a bank holiday, and in the week in August when the phone does not ring. That is the price, and it is a morning rather than a quarter.

Why does the check belong before the write?

Because a run that dies halfway through leaves a half-written result that looks whole. Nothing about a short list announces that it is short. Where the workflow writes as it goes, whoever opens it on Monday cannot tell a finished job from an abandoned one, and will act on it either way.

Most workflows use this order:

Do the work.
Write each piece as it is finished.
Stop when finished, or when something breaks.

The order that survives contact with reality moves the check forward:

Do the work.
Hold the result.
Check it.
Publish it in a single move.

Until the check has passed, the result does not officially exist. Not every job can be held in one piece. Where it cannot, write to a copy and swap the copy in once the check has passed.

Reception at a training studio needs to know each morning who is allowed into a class. The list is rebuilt overnight, group by group, and written as it goes. On group nine the connection to the payment provider drops. At eight in the morning reception opens a list of eight groups and spends the day turning away members whose payment is perfectly in order.

The check does not have to be clever. Three questions usually do it:

Did the process reach the end?
Is the count anywhere near yesterday's?
Are the required fields filled in?

Engineers call these assertions, and the data testing tool Great Expectations defines one as "a verifiable assertion about data". In plain terms it is a rule the automation checks before writing, which fails the run when it is broken.

Failing the run is the point, because a failure is loud. A partly updated list is quiet, and worse than yesterday's list, because yesterday's list is at least honest about its date.

Who can stop the automation, and would you know if nobody could?

Test the stop before you need it. Most stops are a marker somewhere that means "do not run", and where the marker is missing, the system reads permission. Anything that loses the marker, and any copy of the system that cannot see it, carries on working. The default resolves towards running.

Two things go wrong with a marker of that kind. It lives where it was left. A second copy of the system - on another server, in another account, on the laptop of whoever was testing last month - never sees it and carries on. Worse, absence is read as consent: clear a disk, move a machine or restore a backup, and the pause is gone without anybody having decided to lift it.

The office was moving, so a small law practice ticked pause on its automatic case updates, in the copy the partner could reach. A second copy, set up for testing a fortnight earlier and never switched off, does not see the tick. Clients keep receiving letters from a practice that believes it has gone quiet.

The version that holds is a stop living in one place every copy checks, framed as permission rather than prohibition. Work continues while a valid permission exists, and a permission with an expiry date is the cheapest form of this. The cost is that somebody has to renew it, and the work stops on a Monday when the person who signs is away. That is the trade: a system that stops when it is forgotten, instead of one that runs when it is forgotten.

Shopify shows what this looks like from the delivery end. It sends your system a notification every time an order changes. When it cannot deliver one, it tries up to eight times over four hours, and after a day of failures it stops sending that kind of notification altogether. Once it stops, nothing is queued and nothing is retried. There is no error to find, because there is no longer anything trying.

Fail closed or fail open: which mistake is cheaper?

All of it reduces to one decision, and it has to be made on purpose, one automation at a time. Fail open means carrying on when the system cannot tell whether it is right; fail closed means stopping and fetching a person. Nobody choosing gets you the first one, and it is the option that fails quietly.

The argument was settled in print in 1975. Jerome Saltzer and Michael Schroeder, writing on the design of secure computer systems, recommended basing decisions on permission. A mistake in a permission-based mechanism "tends to fail by refusing permission, a safe situation, since it will be quickly detected". The other kind "tends to fail by allowing access, a failure which may go unnoticed in normal use". Half a century on, that sentence describes a misconfigured enquiry router as well as it described a mainframe.

Fail open keeps winning by default because stopping has a visible price and carrying on does not. A stop costs a bad morning: a phone call, some work done by hand, an apology to somebody who was expecting a reply. Carrying on wrongly can cost a quarter.

Buyers at an estate agency get saved-search alerts by email. After a website update the budget field stops arriving from the form. Fail open sends everything, so buyers receive lists where half the properties cost twice what they asked for. A few unsubscribe. Nobody complains, and the agency works it out six weeks later from the response rate. Fail closed sends nothing that morning and puts one line in the owner's inbox: missing field, zero sent.

Some cases are not close at all. Sending nothing today costs you a day, while sending a demand for money that arrived last week costs you the client's belief that you read your own books. So an invoice chasing sequence reads payment status immediately before it sends, never on a schedule.

The bill for silence does not arrive as an invoice, which is why it so rarely appears in a quote. Upkeep is the third cost in what automation costs a small business, and this is most of what it pays for.

One number is useful here, with its limits stated. Monte Carlo and Wakefield Research surveyed 200 data professionals in 2023. Of those, 74 percent said business stakeholders spot data problems first, all or most of the time, up from 47 percent the year before. Those are data professionals with tooling a small business does not run, answering about their own systems. The direction is the part that transfers: the people who notice tend to be the ones being served.

So the question to answer out loud, for each automation you run: which is more expensive, this not working, or this working wrongly? Where wrong costs more - money, client messages, legal deadlines, medical records - the system should stop on any doubt. Where the stoppage costs more, carrying on is defensible, as long as carrying on in doubt is written down somewhere a person actually looks.

What to ask whoever builds this for you

Six questions cover it, asked before the build, of whoever is building it. If that is you, ask them of yourself. No specification is needed, and no understanding of how any of it works underneath. The answers tell you whether the thing will be capable of staying quiet when it ought to be shouting.

What does this send you on a normal day? One line saying it ran, what it found and what it did. Where a healthy day produces no message, a dead day produces the same nothing.
What happens when a step finds nothing? "Found zero" needs to be an outcome with its own name, separate from "did not run" and from "failed".
Can an empty answer overwrite something good? The answer needs to be no, in writing, with a sudden drop in volume treated as a suspicion.
What is checked before anything is written, and what happens when the check fails? Failing the run is the right answer. Carrying on and noting it somewhere is the answer that produces quiet damage.
How is this stopped if the person who built it is unreachable, and is it running anywhere else? Ask to be shown rather than told.
When it cannot tell whether it is doing the right thing, does it stop or continue? Either answer can be correct. What matters is that somebody chose, per automation, and wrote the choice down.

Not one of the six needs technical knowledge to ask, and every one of them is cheaper to ask before the build than to discover after it.

If you would rather have this looked at across everything in your week that repeats, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.