How to Notice an Automation Has Stopped Before a Customer Calls You

Most automations do not fail loudly. They simply stop running. The absence of an action produces no event, shows up nowhere, and therefore nobody notices. It gets noticed when a customer calls, a supplier chases, or a figure in the month-end close refuses to reconcile.

That frames the real question, and it belongs in the conversation before you commission anything. How long may a stoppage last before somebody hears about it? The answer determines what has to be built, and therefore part of the price.

A log is not an alert

A log records what happened. You read it once you already know something is wrong. An alert interrupts a person and demands an action.

Most automations have a log and treat that as monitoring. This is understandable, because every platform ships one without you asking. But a log only answers why something broke after the damage is done. It never answers whether something is breaking right now.

Why a channel full of success messages is worse than none

The usual second step is to have every run post a message into a chat channel or a mailbox. Started, processed, reconciled, finished. After a week there are a few hundred lines a day, nearly all of them unremarkable.

Suppose a genuine error message lands in that stream. It sits there, correct and complete and perfectly visible. Nobody reads it, because nobody reads a channel attentively after it has been irrelevant two hundred times in a row. That is not a failure of the people involved. It is an entirely normal response to a source that is mostly noise.

Meanwhile the channel manufactures a feeling of control it never delivers. It is the most expensive form of monitoring available, because it consumes attention without reducing risk.

The same applies to alerts about known, harmless conditions. A warning that appears every Monday and is dismissed every Monday has stopped being a warning. It has trained its recipients to skip messages of that shape, and the habit carries over to every other alert.

What downtime actually costs

The damage comes from duration, not from the fault. So do not reason about how likely an outage is. Reason about the consequence per day of standstill.

Suppose automated order intake from the mailbox stops. The orders are not lost, they are sitting in the mailbox. What is lost is the time to picking, and hanging off that are delivery dates, commitments and possibly contractual penalties. If instead the nightly handover to accounting stops, nobody notices at first and the work simply piles up until month end.

Those two cases justify very different monitoring. The first warrants an alert within minutes to a reachable person. The second is served by a daily summary. Making that distinction is the only way to size monitoring sensibly, rather than either overbuilding it or skipping it.

The case almost no setup covers

A failed run reports itself. A run that never started reports nothing. That is exactly what happens when a credential expires, a schedule is disabled by accident, or the triggering system stops sending data.

The only defence is a check that comes from the other direction: an expectation that a certain number of items has been processed by a certain time, and an alert when that expectation is missed. Building it in costs modest effort, and it is the difference between two hours of standstill and four days.

What belongs in the specification

Four points, written down before anything is built.

First, what gets reported and what does not. Failures and missing runs are reported, successful runs are not. Second, to whom. A named role with a deputy, never a shared inbox. Third, what the message contains: which transaction, where it is stuck, what to do, and where to find it. Fourth, what happens when nobody responds, meaning after what interval the alert escalates and to whom.

The fourth point is the one most often skipped and the one that decides most. Without it, your response time depends on whether one particular person happens to be on holiday.

Three questions for your provider

How do I learn that a run did not happen, not merely that a run failed? Who receives the alert, and what exactly does it say? And what happens to the transactions that piled up during the outage once the fault is fixed?

The third is the hardest. An automation that simply resumes leaves everything from the outage window untouched. One that catches up has to guarantee nothing is processed twice. That is real work, it belongs in a quote, and it is a common reason a very cheap offer turns out expensive.

The recommendation

Before you request quotes, put a number on each process: how long a stoppage may go unnoticed. An hour, a day, a week. That single number decides whether you need a daily summary or an active alert with escalation, and it makes quotes comparable because every provider is costing the same thing.

Then report less. An automation that speaks only when something needs doing gets read. One that announces every success gets muted, and it gets muted on precisely the day it would first have mattered.

Sophera Consulting sets those thresholds with you, builds the monitoring including escalation and catch-up as part of the process itself, and quotes a fixed price for it with no subscription. The entry point is free in the Automation Check.