Why Automations Fail Silently (Check the Trigger)

A recurring job that needs someone awake to start it is not automated. It is a chore with a calendar invite, and the difference only shows up on the morning nobody opens the laptop.

What breaks is the step before the work

The work itself is rarely the problem. The problem is the step before it — the one where a person has to be present for anything to begin.

That step never appears in the diagram. Nobody draws a box labelled "Dave opens his laptop," so nobody notices when it quietly becomes the thing everything else depends on.

Picture the review requests you send after every job. The template is written. The list is accurate. The message is good. And it goes out when somebody remembers to send it. Dave is off for a week in June and no customer gets asked for a review for nine days — and nothing anywhere tells you, because a week with no review requests looks exactly like a week with no jobs.

We lived our own version of that. A content pipeline ran for four days where every downstream piece worked perfectly and nothing shipped. The publishing step ran every two minutes without a single error. Delivery was flawless. The part that started the work lived somewhere else, and when it stopped there was no error, no alert, and no output — four mornings of a machine reporting nothing wrong while producing nothing at all.

graph TD
  C[Calendar reminder] --> H[A person has to be awake to start it]
  H -- the morning nobody opens the laptop --> Z[Nothing runs, and nothing says so]
  H --> J[Job runs]
  J --> W{Does anything watch the result?}
  W -- no --> Q[Silence reads as success]
  W -- yes --> A[It gets loud the moment it fails]

Half your work is already automatic, and the gap isn't where you expect

Most owners are further along than they think, and the gap is never where they expect it.

Take one recurring process — the after-hours lead form, the reorder reminder, the weekly invoice run — and mark each step as either runs on its own or runs when a person triggers it. (The weekend test is the blunt version of the same exercise.)

• The steps that run on their own almost never break. A server does not get busy, take a call, or go on holiday.
• The steps a person triggers break constantly, and quietly, because a missed one looks identical to a day with nothing to do.
• The handoff between the two is where the whole thing fails, and it is the one place nobody thinks to look.

The fix is usually not more software. It is moving one trigger off a person and onto the machine that already does the rest of the job.

Put a number on the silence

Put a number on the silence — it is the only way this stops being abstract.

Say you close one in five of the leads that come through your site, and the average job is worth two thousand. A trigger that quietly stops for nine days, in a month when forty leads came in, is roughly twelve leads that nobody called and a little under five thousand dollars that went to whoever answered first. Nothing broke. Nothing alerted. Your dashboard was green the entire time, because the dashboard was counting the steps that still worked.

Now price knowing: one read-only check, once a day, answering a single question. Did the thing that was supposed to happen reach a customer? That check costs almost nothing and stays quiet unless something is wrong.

Three rules that make a failure loud

Three rules, in order of how much they have saved us.

1. Judge the outcome, not the attempt. Count reviews received, not messages queued. Count leads called, not leads captured. A record that exists is not a job that finished — and measuring the easy thing is exactly how a broken process keeps looking healthy.
2. Silence is the success signal. A daily "all good" trains you to skip the channel, which means the one message that matters arrives in a stream you have already learned to ignore. Make it speak only when something needs you.
3. Make the check independent. If the alarm shares a dependency with the thing it watches, they fail together and you learn nothing. Ours needs nothing but one database read and one request.

The work belongs on the machine that's already running

On the machine that is already running.

Every recurring process has to live somewhere, and the real choice is between a server that is always on and a person who is sometimes available. One of those forgets. Put the work where the rest of the system already is, give it one honest alarm, and let it stay quiet.

Then the question stops being did it run this morning — a question you should never have been spending attention on — and becomes what do I want it to do next.