No error message does not mean everything works
An automation is like an employee who never complains. When it works, nobody notices it — and for that very reason, nobody notices when it stops. No error message arrives, nobody calls, the inbox is quiet. Three weeks later you find that supplier invoices haven’t been processed since the first of the month, or that new orders from the e-shop never reached the warehouse.
Quiet is not proof. Silence can mean everything is running, but just as easily that nothing has happened at all. An automation that received no input and one that is calmly processing a thousand items look the same from the outside: nothing seems to be going on.
So for every automation it is worth asking one question: how will I find out it has stopped before my customer does? If the answer is “we’d notice”, you don’t have monitoring. You have hope.
Five quiet failures that keep recurring
The most common causes aren’t dramatic. They are mundane and they come from outside. The first is an expired login: the connection to your accounting system, email or file storage works for as long as the permission you once granted remains valid. A password changes, an access token runs out, the employee whose account everything was linked to leaves — and the automation quietly stops.
The second is a change on someone else’s side. Somebody adds a field to a web form or renames an existing one, and data starts arriving empty or in the wrong place. A supplier changes the look of their invoice — a different order of fields, a different name for the VAT column — and invoice reading starts returning blanks. A service provider adjusts its interface and the old connection no longer understands the replies.
The rest is ordinary operations: a full mailbox that no longer accepts new messages, or a scenario somebody switched off while testing or changing a payment plan and forgot to switch back on. In every case there is the same lack of an error message. Work simply piles up that was supposed to do itself.
Monitoring that makes sense for a small company
Good monitoring for a small company is not a big dashboard full of graphs. It is a few simple things. First: the alert must reach a person who can fix the problem, and in a place where they will notice it. An error message that lands in a mailbox nobody reads is as bad as none. Names and contacts belong to the setup just as much as the automation itself.
Second is a regular heartbeat. Once a day or once a week the automation sends a short message: “Ran today, processed 14 invoices and 3 orders.” The key is that the message arrives even when the result is zero. When the heartbeat is missing, something is wrong. And when it arrives with a zero on a day that normally brings twenty items, you see the problem before the customer reports it.
Third: watch for what did not happen. The most dangerous failures raise no error, so no orders for half a day in an e-shop that receives them every hour is a more reliable alarm than any log.
Check the outcome, not just the logs
Logs say the automation tried to do something. They don’t say whether it worked. A scenario can report “done” while sending an invoice to a system that quietly discarded it. It is more reliable to check the result: did the invoice appear in the accounting system? Did the order reach the warehouse with the same number of items? Was the confirmation email actually delivered to the customer?
In practice this is usually a simple checking step at the end: the automation verifies that the record really exists, or once a day compares counts — how many orders are in the e-shop and how many in the warehouse. A difference is an alarm.
This check isn’t free and it doesn’t pay off everywhere. Where a mistake hurts — money, invoices, customer orders — it is worth it. For internal notes or helper reports, a heartbeat and an occasional glance are enough.
Retry, or stop and call a human
Not every error deserves the same reaction. Temporary outages — a service was briefly unavailable, a connection dropped — often fix themselves. Here it makes sense for the automation to try again in a few minutes, then in an hour, and only after several failed attempts let a person know.
Other errors are not solved by repeating, only made worse. If a supplier’s invoice looks different and the data can’t be read, a thousand attempts won’t help. If a payment can’t be matched to an order, guessing is worse than waiting. In those cases the item should stay where it is, marked “waiting for a person”, and must neither get lost nor be processed halfway.
Decide in advance when you retry, when you stop and when you send an alert. And the items that are waiting must be visible somewhere — in a list someone actually opens. Otherwise “waiting for a person” turns into “lost”.
One page of paper — and when not to overdo it
Behind all of this stands a single page: a simple runbook. Nothing about it is technical. For each automation it says what it does, who gets the alert, what that person should do first (check the login, look at the list of waiting items, switch the scenario off and on), whom to call if that doesn’t help, and how to do the work by hand until it is fixed. A deputy for holiday periods belongs on the page just as much as the main person.
Read it as someone seeing the automation for the first time. If the page isn’t enough for them, it won’t be enough for you in six months. And once in a while rehearse a failure: cut off an access and watch who notices and how fast.
On the other hand, not every automation needs this much care. A helper that compiles an internal summary once a week gets by with a heartbeat. Adding checks everywhere would be extra work nobody wants to maintain — measure the care by what a mistake costs. When we build automations for companies, we are happy to set up monitoring from the start rather than afterwards.