# Set one schedule running
> **What you will learn**
> Not a chapter to read but one to **do**. Set up one recurring schedule, then
> **make it fail on purpose** to see what happens when nobody is watching.
## What you need
```
□ 25 minutes
□ A workspace with at least one tool enabled
□ One small job you repeat weekly or daily
· something that looks things up and tidies them — start with nothing that goes outside
```
**Keep that last line.** Make your first schedule an email send and the first
thing you learn will be something you cannot undo.
---
## Step 1 — Queue it once first (5 min)
Do not go straight to recurring. Queue **a single run.**
```
Tomorrow at 09:00:
Count the enquiries logged over the last 7 days by type and lay them out in a table.
Use only the numbers you retrieve; do not estimate.
```
### What to look for
```
□ Did it appear in the queue?
□ Is the run time the one you meant?
□ Can you cancel it right now?
```
**Check the second.** A mismatched timezone, or a different reading of
"tomorrow," is the most common surprise on a first schedule.
---
## Step 2 — Promote it to recurring (5 min)
Once the single run worked, turn the same instruction into a repeat.
```
Every Monday at 09:00
```
| To check | |
|---|---|
| Is the next run time shown? | □ |
| Is there a pause? | □ |
| Does the schedule survive a pause? | □ |
**Press it and see for yourself on the third.** Mistaking pause for delete is a
common reason people never use it.
---
## Step 3 — Make it fail on purpose (10 min)
**This is the point of the exercise.** Nudge the instruction slightly off so it
fails.
```
Point it at something that does not exist:
"enquiries logged over the last 7 days" -> "return approvals logged over the last 7 days"
(if no such data exists, leave it as is)
```
### What to look for
| What happened | Verdict |
|---|---|
| Left "no data" and stopped | ✓ properly designed |
| Produced an empty table and marked itself complete | **the dangerous one** |
| Filled in plausible numbers | **fix the instruction immediately** |
**If you got the second or third,** add these two lines and run it again.
```
If you cannot find the data, do not produce a result — leave only "no data".
Use retrieved numbers only; leave blanks where there are none.
```
**When a person is watching, the person stops it. A schedule has no such
person.**
---
## Step 4 — Tidy up (5 min)
```
□ You turned off or deleted the practice schedule
□ For anything you kept, you checked the next run time
□ You put the two failure lines into the real schedule
```
---
## Self-check
```
□ You went queue-once first, then recurring
□ You confirmed pause is not delete
□ You made it fail and saw what got left behind <- skip this and you did not do the exercise
□ You wrote the failure behaviour into the instruction
```
---
## Check yourself
**1. Why make your first schedule something that does not go outside?**
Answer
**So a mistake can be undone.** First schedules usually have the time or the scope
slightly wrong, and if that is an email send, it cannot be taken back.
**2. Why make it fail deliberately?**
Answer
**To see what gets left behind when nobody is watching.** An empty result marked
complete, or invented numbers, are things no one catches — unlike work a person is
sitting in front of.
**3. What must a scheduled instruction always contain?**
Answer
**The behaviour on failure.** An instruction to leave it alone rather than produce
something is what stops wrong output from quietly accumulating.
---
Next, the ways in from outside → [Channels — the ways in](/guide/cn-channels)