Why "it didn't throw an error" isn't the same as "it worked"
An automation that crashes is, in one sense, doing you a favour: it's telling you something's wrong. The failures worth worrying about are the ones that don't announce themselves, a step that runs, produces something that looks plausible, and is quietly incorrect. Nothing flags it, nobody's told, and the only sign anything went wrong is whatever it eventually causes downstream.
The two kinds of failure
- Loud failures stop and say so: an error message, a crash, a task that visibly didn't complete. These are inconvenient, but they're easy to notice and usually easy to fix once someone sees them.
- Silent failures keep running. The automation does something, just not the right something, and nothing about its behaviour signals that. These are the ones that cost real money, because the gap between the failure happening and someone noticing is where the damage accumulates.
What a silent failure actually looks like, playing out
Picture an automated reminder that emails a client once their invoice is seven days overdue. A system update changes how client email addresses are stored, and the automation starts reading the wrong field. Reminders still go out, on schedule, exactly as before, just to the wrong address, or to nobody at all.
Nothing crashes. There's no error to see, because as far as the automation can tell, it did its job: it found an overdue invoice and sent a reminder. The first sign anything's wrong isn't a system alert, it's a client calling to ask why nobody followed up on an invoice they were half-expecting a reminder about. By then, weeks of reminders have quietly gone nowhere, and the real cost isn't the broken field, it's however much of that unpaid, unchased amount has built up in the meantime.
What usually causes an automation to actually fail
- A connected system changes without warning. A format shifts, a field gets renamed, and the rule built around the old version quietly stops matching reality.
- An input the rule never anticipated. Every rule is built around the cases someone thought of. The case nobody thought of is exactly where failures concentrate, which is what the exception path is meant to catch.
- The process around it changes, and the automation doesn't. A new pricing rule, a new approval threshold, a new step added to the process, any of these can make a previously correct automation wrong without it ever throwing an error.
- A system it depends on is temporarily unavailable. What happens to the work waiting on it, does it queue, retry, or quietly disappear, matters as much as the automation itself.
What good failure-handling looks like
- Something that notices. Not necessarily a person watching constantly, but some way of knowing when an outcome doesn't match what was expected.
- A real exception path, decided in advance rather than improvised: where a failed item goes, who's told, and what happens to it next.
- Actual spot-checking, not just an assumption that silence means success, especially early on, while you're still learning how reliable a particular step is.
What a lightweight check actually looks like in practice
None of this needs to be elaborate. A few genuinely workable habits:
- A rough count, compared week to week. If a process usually sends around the same number of reminders or creates roughly the same number of records, a sudden drop to zero, or a spike, is worth a look even before you know why.
- Picking one real example and tracing it properly. Once a week or once a month, follow a single case all the way through and confirm it actually did what it should have, rather than trusting that it probably did.
- One named person who owns noticing. Not necessarily the person who built it, but someone specific, since a check nobody's explicitly responsible for tends to quietly become nobody's job at all.