Home › Risk & rules

The Real Cost of a Failed Automation Is the Unwinding

The expensive failure is not the one that stops. It is the one that keeps running, keeps reporting success, and keeps writing wrong values into the systems you bill from. Zapier's automatic net only trips when a Zap errors 95% of the time, and everything below that threshold is yours to find.

The Bot Desk staff · September 25, 2026 · 9 min read

Ask someone what a failed automation cost them and you will get a number shaped like an outage: it was down for two days, we did it by hand, we lost some time. That is the cheap kind of failure. The expensive kind does not stop. It keeps running on schedule, keeps reporting success, and keeps writing the wrong thing into the systems you use to bill customers, pay suppliers and decide what to do next.

The bill for that is not an incident. It is a multiplication: how many times the workflow ran while it was wrong, how many systems each run wrote to, and how hard each of those writes is to reverse. Nothing in that sentence is about the platform's uptime.

It is worth being concrete about how a workflow gets into that state, because it is rarely dramatic. An upstream field starts arriving empty and the mapping fills the default instead. A picklist value gets renamed and every record lands in Other. A lookup misses and the step, built to be forgiving, writes a blank rather than stopping. In each case the run is green. The platform has nothing to report, because nothing it can see went wrong.

Three clocks, and the money is in the third

Every failure has three: the time to detect it, the time to stop it, and the time to unwind what it did. Stopping is cheap if you have access to the account running it, and not otherwise. Detecting is the clock a platform's own alerting can cover, within the limits in the next section. Unwinding is where the invoice comes from, and it is the one to budget for, because at the moment of the build there is nothing to unwind and therefore nothing to cost.

A workflow that stops is a Tuesday. A workflow that keeps going while wrong is a quarter-end.

Detection lag is the multiplier on the third clock, not a cost in itself. Take a workflow that runs two hundred times a day and is wrong for six days before anyone notices: that is twelve hundred bad executions, and each one wrote however many records it writes. If each execution touched the CRM, the invoicing system and a Slack channel, that is three places to search. What you are pricing is not six days of downtime. It is the query nobody has written yet that can tell a good record from a bad one.

Worth asking, before anything else: who would actually notice? There are three honest answers — a customer, the accountant at month-end, or whoever happens to open the one record that looks odd. All three are slow, and two of them are expensive in ways that have nothing to do with engineering time. Any monitoring you add is competing with that baseline, which is why even a crude check beats none — the craft of making one workflow shout is in automating a weekly report that fails loudly.

The platforms only catch failures that look like failures

All four platforms in the table have error handling, and all of it keys on a step that errors. A run that completes and writes a wrong value is a success by every definition the platform uses. Worth knowing exactly where each one's automatic net sits:

Platform	What happens on its own	What you have to set up
Zapier	Emails the account owner when a Zap "errors 95% of the time it runs and has run more than 20 times in the past 7 days", then deactivates it. The grace period before deactivation exists only "if your account is on a Team or Company plan": 72 hours on Company, 24 on Team. No other plan is described as having one	Autoreplay, which "works to retry any failed steps in a Zap run", is "available as an account-wide setting to Professional Plans and higher" — the page does not say whether it is on to begin with. Custom error handlers, which the troubleshooting page describes only by their result: "A step errored, but a custom error handler ran an alternative workflow"
Make	Automatically retries incomplete executions caused by three named errors — "RateLimitError", "ConnectionError" and "ModuleTimeoutError" — on an "Exponential backoff" schedule, plus those created by the "Retry error handler" with automatic completion enabled	The retry error handler itself. The page does not describe what happens to failures outside those four cases
Power Automate	Nothing automatic in either page read here	A retry policy at fixed or exponential intervals, configured "on a per-action level", and the "try-catch pattern" Microsoft recommends: main actions in a "Try" scope, a "Catch" scope set to run if the Try scope fails
n8n	No alert unless you configure one	An error workflow per workflow, set in Workflow Settings, which "must start with the Error Trigger"

Read the Zapier row again, because it is the only one of the four that watches for a pattern rather than a single failure, and it is still a smoke alarm that waits for the house to be 95% alight. A workflow that errors four times out of ten never reaches the threshold. And a workflow that completes every run while writing the wrong value never approaches it at all, because nothing it does counts as an error in the first place. That is the failure mode this whole article is about, and no threshold on error rate can ever see it.

Retries are a feature, and they are also how one failure becomes many

Only one of the four retries anything without being asked. Make does; Zapier's Autoreplay and Power Automate's retry policy are settings; n8n has neither. Where retrying does happen it is the right default for a flaky network and the wrong default for anything that writes. Microsoft states the problem plainly in its own guidance for Power Platform: "If some parts of a multistep process are repeated and the operations aren't idempotent, inconsistencies might occur. For example, if an operation that inserts a record into Microsoft Dataverse is repeated, it might cause incorrect values in the table. Or, if you repeat an operation that sends a notification to the user, they might receive duplicate messages."

The same page warns about where you put the retry: wrapping several operations and retrying them together "might result in idempotency issues or unnecessary rollback operations". And it names the case that turns a small failure into an expensive one — when a step fails partway through a longer sequence. "It might be difficult or expensive to compensate for all the other operational steps that have already succeeded when one fails."

That is the whole problem in one sentence, written by a vendor. Step four failed. Steps one to three already happened. If the retry wraps the whole sequence, steps one to three run again.

Idempotent is a word that sounds like it belongs to programmers and does not. In a no-code builder it means one concrete habit: before you create anything, search for it, and update what you find. Where a connector ships both a create action and a find or create action, the second one may cost one more unit of whatever your plan meters — the units are compared in tasks vs credits vs seats — and saves the cleanup. If the tool has no search for that object, the equivalent is writing your own key into a field you control and checking it. Either way, the test is simple: run the same input twice on purpose and see whether you get one record or two.

Four kinds of write, in rising order of what they cost to undo

What the automation did	Cost to reverse
Wrote a field in one internal system	Cheap. A query and an update, if you can identify the affected rows
Wrote to several systems that now disagree	Expensive, and the cost is reconciliation, not writing. Someone has to decide which copy is true
Sent something to a person outside the company	Not reversible. An invoice, a rejection, a payment reminder to someone who already paid. You can apologize; you cannot unsend
Triggered another automation	Unbounded until you map it. The second workflow's writes are also yours, and they are not in the first one's run history

The second row deserves more attention than it gets, because it is the one that turns a technical problem into a management one. Once two systems disagree, fixing it is no longer a query: somebody has to decide which number the company is going to treat as true, and that person may not be the person who built the workflow. Meanwhile the wrong copy keeps feeding whatever reads it. The useful question stops being how many records were wrong and becomes how many decisions were made on them.

The third row is the one that changes how you should design. If a workflow can email a customer, move money, or file something with a third party, the failure cost has a floor that no amount of monitoring lowers. That is the argument for a human gate on exactly those steps and nowhere else — and for asking, before you build, who answers for what the workflow did, which is the subject of who is liable when your automation makes a mistake.

Build the unwind before you need it

Four things make a failure cheap, and all four are cheaper to add at build time than at 11pm on the day you find out.

An idempotency key on every write. A stable identifier derived from the source record, so a repeated run updates instead of inserting. This is the single change that converts the retry behavior above from a liability into what it was meant to be.

A stamp on every record the automation touches. Which workflow, which run, when. Without it, find everything this thing wrote last week is a forensic exercise; with it, it is a filter. It is the cheapest line of code in the whole build, and the easiest to leave out.

A reconciliation query, written on day one. One query that compares the source of truth against what the automation produced and returns the rows that disagree. Write it while you still remember what correct looks like. Run it on a schedule, the same way a weekly report should fail loudly.

A kill switch that is not simply turning off the Zap. A flag the workflow checks on every run, so one person can stop it without needing the account that owns it. The failure will be found by whoever is on shift, not by whoever built it.

A first week that produces the numbers

Day	Do this	What it gives you
1	For each live workflow, write down runs per day, systems written to, and whether anything leaves the company	Your multiplier, per workflow
2	Ask of each one: if this produced wrong output today, how would we find out, and who would it be?	The detection clock. The customer would tell us is a real answer and a bad one
3	Add the run stamp to every write in the workflow with the biggest multiplier	The ability to answer what did it touch
4	Write the reconciliation query for that same workflow and run it once against today's data	Whether you already have a problem you did not know about
5	Check each platform's automatic behavior against the table above, and set what is not set	What the vendor will and will not do for you unasked

Day four is the one that earns the week. If a workflow has been live for a year, that first run of the query is where a problem nobody had looked for would show up.

One note on what this article is not. There is no lab here and no measurement: the platform behavior above is quoted from each vendor's own documentation, read in September 2026, and vendors change these settings and thresholds without much noise. Two of the pages quoted here carry their own warning that they were accurate only at the time of publication. Check each vendor's current error-handling documentation rather than this table in six months.