How schedules run
The exact rules behind reminders and schedules: what a run can use, where results go, who pays, timing and time zones, missed runs and failures.
A schedule runs on June's side at its time, whether or not you are online, and posts its result where you set it up. This page has the exact rules; Follow-ups has the everyday steps.
Every Monday at 9:00 Berlin time, remind me to send the week's invoices
Reminders and work runs
- A reminder posts the words you asked for at the time. It runs no model and does no new work.
- A work run gives June an instruction to carry out: check something, read, write a summary. It runs a full reply, which is paid for like one.
What a run can use
A work run uses no tools unless its schedule lists them, apart from the clock. A schedule June sets up in chat lists none unless June added some, so most work runs answer from their instruction and what June remembers: they do not read your integrations, the web or files. Ask June to turn on toolsets for it by name, integrations, web, documents or terminal (what each opens), or list them under Enabled toolsets in the New schedule form. Your connected apps (mail, Drive, Notion and the rest) are all in integrations; an app's own name is not a toolset. To let a schedule use only some of them, name them when you ask, such as "only my work mail": June then saves those connections, and a run reaches no other. June refuses a name it does not know when the schedule is saved, and a run ignores one it finds in an older schedule. When a connection or skill a schedule names is gone at its time (a disconnected mailbox, a skill you lost access to), the run is blocked instead of running without it, and its result names what to reconnect.
- The tools that act as you in the sandbox depend on where the schedule was set up, and a run never joins your tailnet (which ones).
- A run cannot set up, change or remove schedules.
- A step that needs confirmation does not run (why).
- A run stops after 4 minutes without progress, and after 13 minutes in all.
- In one space, one work run happens at a time. Only one run of a schedule waits its turn; a later time that comes while one waits is recorded as skipped.
- A run set up in one of your projects runs in a sandbox of its own, not the project's, and works with your own memory, not the project's.
Where the result goes
- To the thread you set it up in, by default. For a thread on the web or in the app, June also notifies your devices; if none of your phones has notifications on, June asks you to switch them on.
- To Slack, when you ask for it, or when you set the schedule up in a Slack thread: then it posts back in that thread.
- Only to the schedule's history, when there is no thread it can post in.
A result that cannot be delivered is tried up to 3 times. On the schedule's history page, Try delivering again makes the next of those tries now; once all 3 are used, it no longer shows. Try this run again repeats a run that never started or was skipped.
Who pays, and whose connections run
Every run acts as the person who set the schedule up, with their connections. Unless a model is pinned on the schedule, a run uses the space's funding source if it has one, else the creator's ChatGPT plan, else their Claude plan, else June's own model. Ask June to pin one when you set it up.
ClaudeKinds of timing
| Kind | Say | What happens |
|---|---|---|
| Once | "at 14:00 on March 3", "in 2 hours" | One run at that moment, then the schedule is done. The time has to be in the future. |
| Every so often | "every 30 minutes", "every 2 hours" | Runs again that long after each planned time, in whole minutes. |
| On a calendar | "every Monday at 7", "on the 25th of every month" | Runs on each matching day and minute, following daylight saving time in its time zone. |
A run can start up to a minute after its time. A schedule can also stop by itself after a set number of runs.
Time zones
June is not told your time zone. A time you give without one, such as "at 9", is read in UTC. Name the zone when it matters, by city or region: "9:00 Berlin time", "8 am New York time". The Schedules page shows each run's time in the schedule's zone.
Missed runs
By default, if a run's time passes while June cannot start it, the run happens once, as soon as June can, however late. A schedule that missed several times runs once, not once for each, and its next time is counted from then.
While a schedule is paused, nothing runs and nothing is saved up: Resume picks the next time from the moment you resume, and a one-time schedule whose time has passed is done.
When a run fails
A failed run is not repeated on its own. June keeps trying to start a run that never got going, waiting up to a minute between tries, but once a run has started and failed, the next one comes at its usual time.
The Schedules page lists a schedule under Needs attention as soon as its last run failed or was blocked. One failure is enough, and a schedule there keeps its timetable until you pause or fix it.
A run is blocked, rather than failed, when it was not allowed to start: for example, its creator left the organization or lost access to the thread it posts in, the pinned plan was disconnected, the funding source cannot pay, or no plan is able to pay.
If June changes its default model, a work run without a pinned model is skipped, saying so in the schedule's history, until a model is pinned.
Run history
Open history on a schedule lists its runs, newest first. Every run stays listed. Its result is kept, by default, for the last 100 runs and for at most 30 days.
What schedules do not do
- They cannot be set up from an organization's chats on the web: June tries, and reports an error instead.
- They do not run more often than once a minute.
- They do not pause themselves after failures.