A schedule is unattended work an Agent runs later, once at a stated time or on a repeating cadence. Where a mention starts a turn that someone is waiting on, a schedule starts a turn with nobody in the room, under authority saved when the schedule was created. This page covers what a schedule is made of, how one gets created in Slack, what every run rechecks, where schedules appear in Admin, and the limits an admin meets.
What a schedule is made of
Schedules belong to an Agent, target a granted Slack destination or a private DM thread, and record their creator as Runs as. The parts are fixed:
- Owner. One Agent. A schedule cannot silently move to another Agent.
- Destination. Either a channel the Agent holds an active grant for, or the one-to-one DM thread where it was asked for. Group DMs are not supported.
- Runs as. The member who asked. The run uses that member’s eligibility and their personal connections. A private DM schedule stays bound to the member who owns its destination and cannot move to another Runs as member.
- Task. The saved instruction for the run, up to 8 KiB. Content that looks like a credential is rejected on save.
- Cadence. One-time, or recurring on a five-field cron expression with an explicit IANA time zone. Occurrences must be at least five minutes apart.
- Output policy.
postorpost_on_change.
Names are limited to 80 characters and descriptions to 280.
Asking for one in Slack
You create a schedule by asking the Agent, in the channel or the DM where the work belongs.
@revopspost the open pipeline every Monday at 9am Eastern.
The word “schedule” is not required, and there is no separate approval step. A request such as “check this again in 5 minutes and tell me anything new” is enough. Create, edit, pause, resume, disable, and run-now actions apply immediately when the requester is authorized.
Three rules shape what the Agent will accept from a request:
- Recurring and wall-clock schedules need an explicit time zone in the request. “Every Monday at 9am” without a zone is refused rather than guessed.
- Posting only on change must be asked for explicitly. “Tell me anything new” selects
post_on_change; an omitted policy stayspost. - An action on existing work must name that work. The Agent inspects the schedules in scope first, and asks you to disambiguate when two names match.
Deletion is deliberately excluded from the conversational tool. For a delete request the Agent proposes one exact deletion with the schedule’s current version, and deletes only after you confirm.
In a DM, an applied change is acknowledged with a content-free checkmark reaction on the requesting message. In a channel, the Agent’s own reply is the acknowledgement.
What a run does
Cloudflare Cron wakes the scheduler, which admits the due occurrence and dispatches it to the Agent. Before the model is involved, the run re-reads every authority input:
- The Agent still exists, is enabled, and is not archived.
- For a channel destination, the Agent still holds an active grant on that channel.
- The Runs as member is still an active member of the workspace.
- Every connection the schedule requires still resolves for that member.
- The saved destination still matches the authority record.
If any of that has changed, the run does not proceed. Chickpea never silently reassigns work to someone else.
A channel result arrives as an ordinary message from the Agent, in the channel, or in the request’s thread when the schedule was asked for that way. A DM result returns to the stored origin thread with a completion header and a context line naming the schedule and the run time.
When a run posts
| Output policy | What the run posts |
|---|---|
post |
Every successful result. |
post_on_change |
Only when the result changes. |
Under post_on_change the run must supply a change key. When the key hashes to the same value as the previous run’s, the occurrence is recorded as a no-op and nothing is posted. A run that returns no change key under this policy fails as an invalid result rather than posting.
When a schedule stops itself
| Cause | New state |
|---|---|
| Three consecutive failures the schedule is accountable for (credentials unavailable, policy denied, deadline exceeded, a tool failed, an invalid result) | Paused |
| A result may have been delivered without a confirmed outcome | Paused |
| The private DM thread is no longer reachable | Paused |
| The creator or the channel became ineligible, the assignment is missing, or access was denied | Disabled |
| A required connection is not ready | Needs attention |
A paused recurring schedule produces one content-free notice at its destination: “Chickpea paused scheduled work after repeated failures. Ask Chickpea in this channel to list schedules and resume it after reviewing the issue.” Failure cannot stay invisible, and the notice never carries the result. Suspending a member in Admin pauses the scheduled work running as them.
Where schedules appear in Admin
An Agent’s profile has a Schedules tab. It lists each schedule with its status (Active, Paused, Needs attention, or Completed), its cadence, its channel, and its next and last run, and offers Pause, Resume, and Delete to members who may edit that Agent. Deleting removes the saved schedule and stops all future runs, and cannot be undone.
Audit logs → Scheduled work is the deployment-wide view: Name, Scope, Schedule, Status, Last run, and Next run, with per-schedule run history, revisions, and audit events.
Two boundaries apply to both surfaces:
- Private DM schedules never appear. Admin filters for channel destinations before counting, ordering, and paging, so private work cannot affect a shared count. The Schedules tab carries the note “Private DM schedules are not shown here. Manage them in the Chickpea DM where they were created.”
- Private-channel content is withheld from non-members. A viewer who is not in the destination channel sees the schedule’s status and timing, and its name and task read as restricted.
Limits
| Limit | Value | Scope |
|---|---|---|
| Minimum interval between occurrences | 5 minutes | One schedule |
| Active schedules | 20 | One channel |
| Active schedules | 100 | Deployment |
| Run-now starts | 10 per rolling day | Deployment |
| Concurrent runs | 1 | One schedule |
| Concurrent runs | 4 | Deployment |
| Task text | 8 KiB | One schedule |
Reaching a limit refuses the save or the start; it never drops an existing schedule. The deployment also caps projected daily starts, so a five-minute cadence that would fit on its own can still be refused when the deployment is already busy. The complete set of enforced values lives on the limits reference page.
On Node
Node runs no scheduler. A scheduling request fails closed: “I couldn’t complete that scheduled-work action because scheduling is unavailable on this deployment.” Nothing is created and no run is queued. Resuming a schedule is refused for the same reason. Inspection, pausing, disabling, and deleting still work, so a deployment moved to Node can be wound down rather than left running blind.
Why it works this way
An unattended run is the one turn where nobody is watching, so it gets the least benefit of the doubt. Authority is bound once at creation and re-read at every occurrence, rather than carried along inside the schedule, because a grant removed on Tuesday should stop Wednesday’s run without anyone remembering to go and cancel it. That is also why a schedule pauses instead of retrying forever: three accountable failures is enough evidence that something upstream needs a person.
The private boundary is an omission rather than a redaction after retrieval. Admin never loads private DM schedules, so their existence cannot leak through a count, a page boundary, or a total.
What is not covered
- Schedules are not created in Admin. Admin inspects, pauses, resumes, and deletes them; creation and editing happen by asking in Slack.
- A schedule is not a workaround for a missing grant. It can only reach the channels and connections its Agent and its Runs as member already have.
- Group DM scheduling does not exist.
- Node has no scheduler. Scheduling is Cloudflare only.
Next steps
- What an Agent is: what an Agent is made of, and the grants and connections a schedule inherits.
- Conversations: how a request in a channel or a DM reaches one Agent.
- Admin: the browser app, its roles, and the audit views.
- Authority and confirmation: how authority is bound, stored, and re-checked at each use.
- Cloudflare: the Cloudflare scheduler and what an operator watches.