Automation that fails silently is worse than manual work. Who is responsible, which alerts are mandatory, and how to check something genuinely ran rather than merely reported success.
Key takeaways
- Silent failure is the central risk, not noisy failure.
- Every automation needs a named owner, including one built by an external provider.
- An error alert is not enough; you also need an alert on silence.
- Success is not measured by it running but by the outcome happening.
Manual work that stops is noticed immediately; automation that stops looks exactly like automation that works. That is the only difference that truly matters, and it is why every automation needs two things that are not part of it: a responsible person, and an alert that arrives when it did not do its job.
The three kinds of failure
| Kind | How it looks | How you find it |
|---|---|---|
| Visible error | The run failed | An alert from the tool |
| Silent failure | Ran successfully, did nothing | Only by a deliberate check |
| Partial failure | Some records went through | Comparing numbers |
Row two is the dangerous one, because every ordinary indicator shows "fine". Automation pulling from a source whose structure changed can run beautifully and transfer zero records - and that looks exactly like success.
What every automation needs
- A named owner - who is accountable for it working, not who built it.
- A one-line description - what it does, in language somebody who did not build it understands.
- An error alert - who receives it, and on what channel.
- A silence alert - when it did not run at the time it should have.
- An outcome check - not only that it ran but that the numbers match.
- What to do manually when it is not working.
The last item is forgotten and matters especially: when automation fails on a busy day, somebody has to know how to perform the process by hand - otherwise the fault stops work until whoever built it is available.
Why an error alert is not enough
Because it only covers the first kind. Automation that never ran at all - because somebody switched it off, because a subscription lapsed, because a password changed - will send no error, simply because it did not execute.
The fix is an inverse alert: if no run confirmation has arrived by a given time, send a message. It sounds trivial and most businesses do not do it - which is precisely why failures surface a week later. The technical side of silent failures is covered in monitoring silent failures in Zapier and Make.
The outcome check - what you actually measure
The right check is not "did it run" but "do the numbers add up". Two simple examples: how many orders were created in the system against how many arrived from the store; how many documents were issued against how many payments were received.
A consistent gap between the two means something is being filtered along the way, and it is usually an edge case nobody accounted for - an order with two different item types, say, or a customer missing a mandatory field. That gap will appear in no alert, and it is found only when somebody compares.
Who should be the owner
Not necessarily whoever built it. The owner should be whoever cares about the outcome - usually the owner of the process the automation serves. They do not need to know how to fix it; they need to know when something did not happen and who to call.
When the automation was built by an external provider, this matters especially: an outside provider will not know something failed to happen, because they do not see the business outcome. They see only a successful run. The logic of owning an outcome is in who owns a process.
What to review quarterly
- Which automations exist - the list is always longer than anyone remembers.
- Who owns each one, and whether they are still in that role.
- When it last ran with genuine success.
- Whether it is still needed - some were built for a process that has changed.
- What happens when it fails - whether anybody knows.
Point 4 usually removes one or two from the list, which is a double saving: less maintenance and fewer places that can break.
What happens with no monitoring at all?
The scenario repeats itself almost identically in every business. The automation is built, works for two months, and something changes - a vendor updates, a field is added, a password expires. It stops, and nobody knows. A fortnight later a customer asks why they never received confirmation, and that is when you find out.
What follows costs more than the fault itself: identifying which records did not go through, completing them manually, and deciding what to tell the affected customers. In businesses where this has happened once, monitoring gets built immediately - which is exactly the lesson available without paying for it.
The cost of monitoring, by contrast, is small: one alert on error, one on silence, and a monthly number check. That is under half an hour to set up and minutes a month.
The monthly check is five minutes: open the list of automations and confirm two things for each - when it last ran successfully, and whether the numbers on the other side look plausible. It does not replace automated monitoring, which stays the first line of defence, but it catches exactly what monitoring cannot: empty successes.
How to review automation you received from a provider
- Ask for a list of what was built, and what each one does in a line.
- Confirm it runs in the business's account rather than a personal one.
- Check who receives alerts - and change it to your address.
- Ask for instructions on doing it manually when it fails.
- Ask what happens if you stop working with the provider.
The last surprises people at the worst moment. Automation running in an external provider's account stops the day the relationship ends, and that is usually remembered exactly then - so establish it at the start of the engagement rather than at the end. The same applies to the accounts the automation connects to: they should belong to the business, not to whoever set them up.
Sources
Frequently asked questions
How much time does maintaining automation take?
Little, when it is simple and monitored - usually minutes a month plus a quarterly review. What consumes time is change: every time something in the environment shifts, somebody has to adjust. Which is why automation touching fewer systems lasts longer.
What if whoever built it has left?
Check three things in order: whether there is a one-line description of what it does; whether there is access to the account it runs in; and whether there is a way to perform the process manually. The second is critical - automation running in a departed person's personal account is a time bomb.
Email alert or message?
Whichever channel gets read. An alert arriving in an inbox nobody opens is equivalent to no alert. More important than the channel is that it has a named recipient rather than a generic address - an alert to info@ is read, on average, never.
How many automations are too many?
When you cannot list them all from memory. It is not a fixed number but a signal: when there are more than you can hold in your head and no list exists, nobody notices when one stops - and that is exactly the point where automation stops saving and starts costing.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.