What happens when an automation gets it wrong?
It depends entirely on how it gets it wrong. Most tools are built to survive the failures that are easy to see. The failure that costs you money is the one that looks exactly like success.
Two kinds of wrong
When people ask whether they can trust an automation, they are usually picturing a crash — the thing stops, something goes red, someone gets an alert. That kind of failure is loud, and loud failures are cheap: you notice within minutes and fix them before they spread.
The expensive failure is the quiet one. The automation runs, reports success, and does the wrong thing. Nothing errors. No alert fires. The mistake sits in your data until a person trips over it — a member billed twice, an attendance report built on the wrong week, a message sent to someone who left months ago.
A crash is caught by the system. A wrong action that looks like a right action is caught by a human — usually the customer, usually later, usually at the worst possible moment.
How most tools actually handle failure
This is worth being precise about, because the popular automation platforms are genuinely well engineered — just for a different problem than the one that hurts you. Their reliability model is infrastructure resilience: retry a step when an API times out, roll back a partial run, undo a charge if a later step fails. All sensible. All aimed at system errors — rate limits, timeouts, dropped connections.
Here is the tell. On one major platform, a workflow is only switched off automatically after 95% of its runs have failed over the previous seven days — and that is the documented, default safety mechanism. It is a reasonable design for catching total breakage. But read what it implies: a workflow can get things wrong one time in twenty, every day, for a week, and stay on. The threshold is built to catch the loud failure. It is blind to the quiet one by design, because a single wrong-but-successful action is not an error the system can see.
And when something does need judgment — the input is ambiguous, the data looks off, the request is valid but would create a conflict — the standard answer is that you build a branch to handle it, in advance, for every case you managed to anticipate. There is no native “stop and ask a person.” The tool either proceeds or it doesn’t.
The behaviour you actually want
The question is never “does it retry?” It is “what does it do when it isn’t sure?” A system you can leave alone has four responses, not one:
- clarifieswhen the instruction is unclear — instead of guessing
- declineswhen the action is risky or would create a conflict — instead of proceeding
- executeswhen the conditions are actually right
- escalateswhen a human should weigh in — before anything is changed, not after
A tool that only knows how to execute has moved the decision onto you: you become the check that runs after the fact. That is the opposite of automation. The point of handing work over is to stop being the last line of defence — which only works if the system knows when to stop and ask.
Why this is a service, not a setting
Knowing when to stop is not a toggle. It requires understanding what a given request is supposed to achieve, what a bad outcome looks like in your specific operation, and which mistakes are worth interrupting a human for. That is judgment about your workflow, not a feature you can switch on in a generic builder.
It is also why we run this as a managed service rather than sell you a tool to configure. We map how your work actually runs, encode where it’s allowed to act and where it must stop, and stay responsible for the result — so that “what happens when it gets it wrong” has an answer you never have to discover in production.