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