The Job That Only Runs When You Are Watching

What breaks when nobody is watching?

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 writes "Brian opens his laptop" as a box with an arrow, so nobody notices when it becomes the thing everything depends on.

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

Which half of your work is already automatic?

Most operators are further along than they think, and the gap is not where they expect. Go through one recurring process and mark each step as either "runs on its own" or "runs when a person triggers it."

• The steps that run on their own almost never break, because a server does not forget or get busy
• 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

The fix is usually not more software. It is moving one trigger from a person to the same machine that already does the rest.

What does it cost to find out late?

Put a number on the silence. Our content lane targets two pieces a day. Four silent mornings is eight pieces that were never written, on a site where each one is a permanent asset that keeps earning search traffic. The compounding does not pause while you are unaware.

Compare that to what it costs to know: one read-only check, once a day, that answers a single question. Did the thing that was supposed to happen reach the outside world? Ours costs nothing and stays quiet unless something is wrong.

How do you make a failure loud?

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

1. Judge on the outcome, not the attempt. Count published pages, not rows created. A record that exists is not a job that finished, and measuring the easy thing is how a broken process looks healthy on a dashboard.
2. Silence is the success signal. A daily "all good" trains you to ignore the channel, which means the one real alert arrives in a stream you have already learned to skip.
3. Make the check independent. If the alarm shares a dependency with the thing it watches, they fail together. Ours needs nothing but a database read and one request.

Where should the work live?

On the machine that is already running. Every process needs somewhere to live, and the choice is between a server that is always on and a person who is sometimes available. Put the recurring work where the rest of the system already is, and give it one honest alarm that stays quiet.

Then the question stops being whether it ran this morning. It becomes what you want it to do next.