Scheduling Automations and Missed Runs

When people build an automation, nearly all the effort goes into what it does. But once it has been running for a while, two other decisions turn out to matter just as much.

What hour it runs. And what happens when it misses that hour.

Both are usually left at whatever the default was. Mine were too, and one of them cost me an entire day of output.

A dark room with several desk lamps, only one of them lit

The failure: the wrong hour produced nothing

I had a writing automation scheduled for 2 p.m. — after lunch, a quiet stretch of the day. It looked like a sensible choice.

On its first proper run, it produced nothing at all. The cause was not the code. I had already used the same tool heavily that morning, so by two o'clock there was no allowance left. The job sat there producing nothing for forty minutes and then timed out.

Moving it to 8 p.m. ended the problem. The working day is over by then, the tool is idle, and it does not collide with anything else on the schedule.

The rule I took from it:

> When choosing the hour, look past your own calendar to the state of the tool the automation depends on.

Anything with a usage cap, a server that is only quiet at night, or a program a person occupies during the day — same story.

Should a missed run catch up?

If the machine was off, or something else was holding the job, the scheduled moment simply passes. You have two options.

Catch up enabled — the missed run starts late, once the machine is back

Catch up disabled — that occurrence is skipped entirely

Most people never touch this setting. Yet the right answer is the exact opposite depending on the job.

Jobs that should catch up — the ones that leave something behind

Writing, filing, backups: work that is still worth doing late should catch up. If it did not run this morning, running tonight is better than not running. My weekly writing jobs and the periodic maintenance job are all in this group.

Jobs that should not — the ones where timing is the point

A morning briefing delivered at four in the afternoon is not a briefing. It is a list of things that already happened. The same goes for a nightly wrap-up of the day — if it surfaces the next morning, the context is already wrong.

For these, catch-up stays off. Skipping the occurrence is the correct behavior.

But what if missing the briefing entirely is also unacceptable?

This is where one more step is needed, and it is the pattern I actually run.

The morning job has catch-up off — and a separate recovery job runs in the afternoon with catch-up on.

Morning job: the normal hour, catch-up off

Recovery job: a second registration of the same work, an afternoon hour, catch-up on

The recovery job's first action is to check whether today's briefing already went out, and exit immediately if it did

On ordinary days only the morning run happens. On a day when the machine was off all morning, the afternoon run fills the gap once. You do not accumulate stale notifications, and you do not get silent days either.

"Must not be missed, but must not arrive late" cannot be solved inside one job. Split it in two and give the second one an early exit.

Three smaller settings

Once the hour and the catch-up behavior are decided, the rest is quick.

1. Spread them apart. Several jobs stacked on the same minute compete for the same machine. Scatter them across morning, afternoon, evening and night; put the weekly check the evening before the weekend and the monthly one in the small hours.

2. Avoid the top of the hour. Round hours are when other software runs its own updates and backups. 19:07 instead of 19:00 removes a whole class of collisions.

3. Decide what happens if the previous run is still going. If the next occurrence starts while the last one is still working, two copies of the same job run at once — duplicated output, or one overwriting the other. Ignore the new instance is usually the safe setting.

On a laptop there is one more. Scheduled jobs often refuse to start on battery power, or stop when the charger is pulled, by default. If you do not want your automation quietly dying when someone unplugs the machine, relax those conditions too.

A five-line check before you schedule anything

At this hour, does the tool this job depends on have capacity? (Not just your calendar.)

Is this work still useful late, or does timing carry the meaning?

If it must not be missed but must not be late — add a recovery run that exits when the work is already done

Does the hour collide with another job, and did you avoid the top of the hour?

If the previous run is still going, is the new one ignored?

When you first build an automation, the feature looks like the whole job. After a few months of running it, most of the failures turn out to come not from the feature but from timing and conditions.

I wrote separately about the four checks that tell you an automation actually finished, and about which automations I kept and which I turned off.