# 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:

| Cadence | Example |
|---|---|
| Every morning | collect and summarise yesterday's errors from the logs |
| Every night | clean up temp files, back up |
| Every Monday | summarise last week's commits into a weekly report draft |
| The 1st of each month | tally usage, check for dependency updates |

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.

| Available cadences | Example |
|---|---|
| Minutes | every 10 minutes |
| Hours | every 3 hours |
| **Daily** | 9am daily (the default) |
| Weekdays only | Mon–Fri at 9am |
| Weekly | Mondays at 9am |
| Monthly | the 1st at 9am |

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

```
✗ "Every morning, summarise yesterday's sales and tell me"

✓ "At 8am daily, summarise yesterday's sales and tell me.
   If the data lookup fails, don't summarise — tell me it failed.
   Do not estimate or fill in blanks."
```

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

### 2. Have it verify preconditions

```
✓ "Sales data refreshes via a 6am batch.
   If it hasn't refreshed, wait 30 minutes and check again,
   and if it's still missing, tell me."
```

Checking the data refresh cadence in
[Phase 2 assessment](/guide/ax-phase2-assessment) is used directly here.

### 3. Start with low autonomy

[Autonomy levels](/guide/ht-autonomy) said to use "fully automatic" for
**verified, repeated work.** A scheduled run is repeated work, but **it is not
verified at the start.**

```
Week 1: schedule it as plan only → read the plan daily
Week 2: auto-approve file edits
After:  fully automatic (the default) once stable
```

### 4. Decide where the result goes

```
□ leave it on screen only  → likely nobody looks
□ receive it as a notification → checkable on a phone
□ write it to a file       → reviewable later
```

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

## When schedules accumulate

As schedules multiply they need managing.

| Check | Why |
|---|---|
| When did this schedule last succeed | it may be failing quietly |
| Is this schedule still needed | schedules whose purpose is gone keep running |
| How much does it cost | daily runs accumulate |

**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.

```
$0.10 per run × daily × 30 days = $3/month
$0.50 per run × daily × 30 days = $15/month
```

Not large, but ten schedules is different. As with
[model routing](/guide/ha-guardrails), **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](/guide/ht-first-run) is set up.

---

## Check yourself

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

<details>
<summary>Answer</summary>

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

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

<details>
<summary>Answer</summary>

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.
</details>

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

<details>
<summary>Answer</summary>

**Schedules whose purpose is gone keep running.** The project ended but the
schedule remains, spending money daily.
</details>

---

Now make it reachable from outside →
[Access from anywhere](/guide/ht-remote-access)