When Your Automation Reports Success and Does Nothing

We run a content pipeline that publishes on a schedule. Every scheduled run for a full week finished, reported success, and published nothing at all. There was no alert because there was no failure — the job had done exactly what it was written to do, which was to attempt the work and exit cleanly whether or not the work happened. We found it by looking at the website and noticing the newest post was seven days old.

That is the failure mode worth designing against, and almost nobody does. A broken automation announces itself. A silently idle one does not, and it can sit there for weeks looking healthy on every dashboard you own.

Why 'success' is a much weaker word than it sounds

Most automation tools — schedulers, CI runners, Zapier-style connectors, cron jobs — report on whether the process completed, not on whether it accomplished anything. Those are different questions, and the gap between them is where this failure lives.

A job can complete successfully having done none of the following: found any records to process, obtained a valid credential, reached the API it needed, or written a single row. It ran. It handled the empty case gracefully. It exited zero. Green tick.

Worse, the well-behaved engineering habit of failing gracefully makes this more likely rather than less. Code that catches an error, logs a warning and continues is code that has been explicitly designed not to raise an alarm. That is correct behaviour for a transient blip and completely wrong for a condition that will persist for a week.

The four causes we see most

• An expired credential. A token, API key or OAuth grant lapses. The integration catches the auth error, logs it, and reports success. The sequence keeps 'running' and nobody receives anything.
• A billing or quota stop. The account behind the service hits a spending limit or a failed payment. The provider stops accepting work. The scheduler that calls it treats the rejection as an empty result.
• An empty input the job was never told to complain about. The queue it reads from is empty because the upstream step that fills it broke. Downstream sees zero items, processes zero items, reports success.
• A filter that quietly matches nothing. Someone renames a tag, list or field. The automation still runs, still matches its criteria, and its criteria now select no one.

In every one of these, the status dashboard is green and the output is zero. The status dashboard is not lying — you asked it the wrong question.

Monitor the output, not the run

The fix is a change of subject. Stop asking 'did the job run?' and start asking 'did anything come out the other end, and when?' Concretely:

• Alert on staleness, not on errors. Set a rule that fires when the newest record is older than the schedule allows — no post published in three days, no email sent since Monday, no lead written since yesterday. Staleness catches every cause above at once, including causes you never anticipated.
• Make a zero result loud. If a scheduled job processes nothing, that should be a warning, not a silent pass. Doing nothing is unremarkable once and suspicious three times running.
• Count the thing you care about, at the end. Have the job report a number — items published, emails sent, rows written — and log it. A run that reports 'sent 0' is instantly readable in a way that 'completed' never is.
• Check the artefact, not the process. The most reliable monitor for a publishing pipeline is a request to the live page. The most reliable monitor for a send is the row in the sending log. Verify the outcome in the place your customer would see it.
• Give the alert somewhere to land. An alert into a channel nobody reads is the same as no alert. One person, one inbox, one clear message that names what is stale and for how long.

Green means the process finished. It has never meant the work happened. Monitor the output, and the difference stops mattering.

How much a quiet week costs

Nothing dramatic happens the day an automation goes quiet, which is why it survives so long. The cost accrues instead: a nurture sequence that stops touching a warm list, a publishing schedule that breaks its own cadence, a lead router that stops routing while the forms keep collecting. By the time someone notices, the fix takes ten minutes and the missing weeks cannot be recovered.

If you run any automation your revenue depends on, do this today: pick the one thing that automation is supposed to produce, find where that thing gets recorded, and set an alert for when it stops appearing. It is a small piece of work. It is also the difference between finding out on day one and finding out the way we did — by looking at the website and doing the arithmetic.

← Back to all articles