Scheduled runs

What you will learn What to hand to a schedule, and what you have to design differently when nobody is watching.

What to hand over

It starts a task or runs a command at a set time.

Typical cases:

What they share is being work someone has to remember. You hand that to the clock.

Where to turn it on

On the new-task screen, enable Schedule and a cadence picker appears.

For a cadence not in the list, switch to manual entry and write a cron expression directly (0 9 * * * form). The default is 0 9 * * * — 9am daily.

Tasks created by a schedule accumulate as a separate task per run. Without a name of their own they inherit the schedule's name, so give the schedule a name if you want to tell them apart in the list.

Designing for when nobody is watching

This is the heart of the chapter. A scheduled run happens when nobody is looking. So it has to be designed differently from ordinary work.

1. Write down what happens on failure

Doing nothing beats producing a wrong result. With nobody watching, wrong results harden in place.

2. Have it verify preconditions

Checking the data refresh cadence in Phase 2 assessment is used directly here.

3. Start with low autonomy

Autonomy levels said to use "fully automatic" for verified, repeated work. A scheduled run is repeated work, but it is not verified at the start.

4. Decide where the result goes

A result nobody looks at is the same as no result.

When schedules accumulate

As schedules multiply they need managing.

The second is common. The project finished but its schedule keeps running.

A sense of cost

Scheduled runs happen every day. Even a small per-run cost accumulates.

Not large, but ten schedules is different. As with model routing, use a light model for simple repetition.

Common mistakes

Not reporting failures

The most common. Fail quietly and you discover it weeks later as "hey, that stopped coming." Make it report failures too.

Not checking that it runs

You build it and forget it. For the first week or two, check the result daily. After that you can let go.

Not accounting for the machine being off

If the computer is off, the schedule does not run. Schedules only mean something when background execution or a startup item is set up.

---

Check yourself

1. Why must you always write down "what happens on failure" for a scheduled run?

Answer

Because nobody is watching. A wrong result hardens in place. Doing nothing and reporting the failure beats producing a wrong result.

2. Why not set a scheduled run to "fully automatic" from the start?

Answer

Because although it is repeated work, it is not verified at the start. Climb plan only → auto-approve file edits → fully automatic, checking for a few days at each step.

3. What is the most common problem once schedules accumulate?

Answer

Schedules whose purpose is gone keep running. The project ended but the schedule remains, spending money daily.

---

Now make it reachable from outside → Access from anywhere