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

Source: https://www.dearjune.ai/docs/how-june-works/schedules

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](/docs/follow-ups) has the everyday steps.

> Example prompt: 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 does not read the conversation where you set it up. Put the source, selection rules and expected result in its instruction. It 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](#set-up-a-schedule-with-the-form)), 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](/docs/how-june-works/connections#tools-that-act-as-you-in-the-sandbox)).
- **A run cannot set up, change or remove schedules.**
- **An integration step that needs confirmation does not run** ([why](/docs/how-june-works/connections#a-step-that-needs-your-confirmation)).
- **A run stops** after 4 minutes without progress, and after 13 minutes in all.
- **By default, one work run happens at a time in its target workspace.** Separate projects can run independently. One later run of a schedule waits its turn; further times that arrive while it waits are skipped. A schedule can instead be configured to skip overlapping runs or allow parallel ones.
- **A run targeting an organization’s project** uses that project’s sandbox and the organization/project memory available there, without the creator’s personal memory. The place the schedule targets matters, not just where its result is delivered.

## 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. The space’s [funding source](/docs/organizations/funding) takes priority when one is set, including for a run with a pinned model. Without one, a run with no pinned model uses the creator’s ChatGPT plan, then their Claude plan, then June’s own model.

A pin chooses which model and plan the run requests; it does not bypass the space’s funding rules or restore an unavailable plan. Ask June to pin a model when you set it up.

## Kinds 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. |

June checks for due schedules every minute. Queued work or retries can delay the start further. A schedule can also stop by itself after a set number of runs.

## Time zones

If no time zone is supplied for the schedule, June uses UTC. Include a zone explicitly when you ask, rather than relying on an earlier message. 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.

Open **Open history** to read the reason before retrying. Reconnect an unavailable account, restore access, or revise the instruction as appropriate. Use **Run now** to test the fix; pause the schedule while investigating if more runs would be unhelpful.

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

- In an organization chat, a schedule stays in that organization. Public threads cannot list or control schedules from private chats or Slack DMs.
- They do not run more often than once a minute.
- They do not pause themselves after failures.

## Set up a schedule with the form

1. On the **Schedules** page, choose **New schedule** and give it a **Name**.
2. In **Execution body**, write the whole instruction. The run does not reread the thread you discussed it in, so name the repositories, senders and files.
3. Under **Delivery**, leave `local` to keep the result under **Open history** on the schedule, or enter `slack` for a direct message from June in Slack (you need to have messaged June there once), `web` for your newest own chat, `web:` and a chat's id (the last part of its address) for that chat, or `push` for a notification on your devices. Several are separated by commas.
4. In **Expression**, enter the time as five fields: minute, hour, day of month, month, weekday. `0 7 * * 1-5` is 7:00 Monday to Friday, `0 9 * * 1` is 9:00 every Monday. Put your zone in **Timezone**, such as `Europe/Berlin`.
5. Under **Enabled toolsets**, list what the run may use, separated by commas. Left blank, the run cannot read your connected apps, the web or files.
6. Choose **Create schedule**. The schedule's own page opens; choose **Run now** there to try it.

| Enter          | So the run can                                                                                                                 |
| :------------- | :----------------------------------------------------------------------------------------------------------------------------- |
| `integrations` | read and draft in the tools on your **Integrations** page: your mailbox, Microsoft 365, Notion and the others there            |
| `web`          | search the web                                                                                                                 |
| `documents`    | read Google Docs, Slides, PDFs and images in your Google Drive from a link; plain text files there come through `integrations` |
| `terminal`     | work in June's sandbox, including GitHub through the command line                                                              |

Copy them exactly: the form refuses a name June does not know, such as an app's own name instead of `integrations`. The other fields can stay as they are.