Skip to content

Scheduled tasks

Scheduled tasks let any authoring user run a prompt automatically on a schedule — a daily news digest, a weekly report summary, an hourly status check — without building an agent or a workflow. The results arrive as a normal conversation in your chat sidebar, marked with an unread indicator, and optionally by email.

💡 Note: Scheduled tasks are part of the workspace's plan (provisioned by the platform operator; on by default). The Scheduled tasks entry is always shown in the left rail; it carries a Premium badge and its pages redirect to the upgrade page when the feature is not part of the workspace's plan, or when the user may not author scheduled tasks (viewer, demouser, finance, or a custom role without the capability).

Creating a task

Open Scheduled from the Workspace cluster of the left rail (the page heading reads "Scheduled tasks") and choose New scheduled task:

  1. Name — how the task appears in your list and as the title of its result conversation.
  2. Prompt — the exact text sent to the model on every run.
  3. Model — on self-serve plans, the models included in your plan.
  4. Schedule — daily or weekly at a time of day (your local time), or a fixed interval (at least one minute, at most 366 days).
  5. Email (optional) — additionally send each result to an email address.

The time you enter is converted to UTC internally: across a daylight-saving change the run time therefore shifts by one hour. The first run of an interval task starts within about a minute of creating (or resuming) it — a quick way to see that it works. A daily or weekly task instead runs first at the next occurrence of its configured time. The configured schedule applies from then on.

Results

Each run appends your prompt and the model's answer to the task's result conversation — the same conversation every time, so a daily digest builds up a readable history. The conversation shows an unread dot in the sidebar until you open it. If you delete the result conversation, the next run simply starts a fresh one.

Email delivery (when configured) is suppressed automatically if the run touched protected personal data on a PII-enabled gateway — the conversation still receives the result, but nothing leaves the platform.

Scheduled tasks can use web search automatically whenever the gateway they run on has web search configured — the same gateways on which the web-search globe appears in chat. There is no per-task web-search switch: web search is offered on every run, and the model searches the web when the prompt calls for up-to-date information, just as it would in an interactive chat on that gateway with the globe on. On a gateway without web search configured, scheduled tasks run without it (nothing is silently enabled), and the platform's residency and personal-data protections apply to a scheduled search exactly as they do in chat.

The scheduled-tasks panel

Above the task list, two stat tiles summarise your schedules: Active schedules — the number of currently active (non-paused) tasks — and Next run — when the soonest upcoming run is due. Each task row opens via its explicit row action.

Limits and fair use

  • Active-task cap: the paid Custom plan includes 10 active scheduled tasks (the free trial 0) (enterprise setups have their own limit). Paused tasks do not count; pause or delete a task to free a slot.
  • Fair use: scheduled runs draw from the same monthly allowance as your chats. Over the allowance, runs continue on your plan's efficient model (soft-degrade) instead of failing — premium models unlock again when the allowance resets (or after an upgrade).

Reliability

Transient provider errors are retried automatically (up to three attempts per occurrence). A permanently failing task — for example after its model was retired — shows the failure in the task list and pauses itself after five consecutive failed runs, so an unattended task can never quietly burn your allowance. Resume it anytime after fixing the cause.

When a run fails, the task owner is notified so the failure does not go unnoticed. To avoid a flood from a task that fails on every run, at most one failure notice is sent per task in any 24-hour period. The notice names the task and that it failed; it never contains the run's content, so nothing sensitive leaves the platform in a failure alert.