Scheduled tasks and watchers

Some work has no conversation in it: it has a time on it, a change to notice, or a message arriving from somewhere else. Player One has three small parts for that. Make it repeat shows them at work; this page says what each one is.

A scheduled task

A scheduled task is one agent, one instruction, on a clock. "Summarise yesterday's orders every weekday at eight" is one, and so is "remind me at three on Thursday", which fires once and then removes itself. Say your timezone with the time: your installation keeps its own clock, and an eight o'clock briefing without one can land hours out.

One task can fire at several times. "Mondays at two and four, Thursdays at one and eight" is one task with two rules, each with its own days and its own times, rather than four tasks or one per day. Ask for it in those words and that is how Player One sets it up; on the page it is the task's Times tab, and the list reads it back as "Mon 14:00 and 16:00; Thu 13:00 and 20:00". To change the days or times later, ask for the change and it goes into the same task, so the run history and the failure notices stay in one place.

The two ways it can run

Most tasks run in a fresh chat of their own each time. Nothing carries over from yesterday, so the hundredth run works from the same instruction as the first, and whatever it produces needs somewhere to go.

The other way is a nudge: the task drops a note into your main assistant's conversation, which picks it up on its next pass. Nudges cost almost nothing and suit "remember to ask me about the migration". A task set up inside a chat can instead stay tied to it, where its answer simply appears.

Where the answer goes

A scheduled task delivers to a connected channel, leaves the answer in the chat it belongs to, or posts it to an address you give it. It cannot push anything into the web app, where nothing will buzz your phone. So name the channel, and give the recipient's real address or handle rather than a name from your contacts.

Delivery happens on every run, quiet ones included, so a task that found nothing still says so and names itself. That is how you tell a calm morning from a broken schedule.

A watcher

A watcher waits for a change instead of a time: a file that gets written, a page or a value that moves, or a message arriving from outside.

Before it arms, a watcher sends you one message immediately on the channel you chose. That self-test proves the alert path works while somebody is still watching, because a watcher that fails quietly looks exactly like a quiet week.

After that it stays silent until there is news. One that checks repeatedly remembers what it saw last time, treats its first look as the baseline, and switches itself off once the thing it waited for has happened. A watch on a single file lasts until it fires or until your installation restarts, so anything that must outlive a restart is built as a repeating check.

Choose a watcher when the answer is one message. If what follows has an order to it, rules, approvals or several people, that is a flow.

A webhook address

A webhook address is a URL of your own that other software can post to: a form submission, a finished build, a monitoring alert. The simplest kind turns the posted message straight into a message to you, with no agent involved; the other hands the payload to an agent for one turn and delivers what it makes of it.

Ask for one and Player One mints it, with an unguessable address that is itself the secret. Your addresses are listed under Admin > Webhooks (/admin/webhooks), where you can see what each does and revoke any of them.

Where they live

Dashboard > Scheduled (/cron), headed Scheduled Jobs, lists everything running on a clock. Tasks are grouped Running now, Needs attention (the last run failed, or several in a row did), Up next and Paused, which is folded away behind its label and count. Each row shows the task's name, its schedule in words, its agent, its last result over a strip of its recent runs (newest on the right: green for done, red for failed, grey for skipped), and when it runs next. Status and Sort dropdowns above the list narrow it and reorder it, and Recent runs below it shows the latest runs across every task.

Open a task and it has a page of its own: next run, last run, the schedule in words with its timezone, and every past run, newest first. A run opens in place to show its result, its error if there was one, the model, whether it was delivered and a link to the chat it ran in, which answers "did last night's task run". The page also says what the task tells its agent and where its result goes. A link to a task, or to one of its runs, opens straight on it.

You can create, pause and resume, run now, edit, clone and delete from the list or the task's page. Short timers set inside a chat appear here too: you can run, pause or remove one, but not edit or clone it. Clone opens the editor on a copy named "Copy of" the original, with the same schedule and timezone, and saving it makes a new task.

A task belongs to the project it was created in, and its runs do their work there too, so what a scheduled run writes lands with the rest of that project's work rather than in the default one.

A read-only panel on the same page shows flows firing on schedules of their own, each row linking into the Flows page where they are changed. Dashboard (/dashboard) is the wider view: what is running now at the top, and below it what finished in the last day, jobs, flows and scheduled tasks together, with how each ended.

What they cost

A scheduled task spends a little every time it fires, whether or not anybody reads the result, so the interval is the number to watch: daily beats hourly, and every few minutes is almost never what you meant. A watcher that checks repeatedly costs the same way, while a nudge is close to free and a relaying webhook spends nothing. A repeating task that keeps failing does not switch itself off, so pause anything you have stopped reading.

When one breaks

You hear about it without asking. A Scheduled task notice appears in the chat the task belongs to, or in your main chat if it has none: "Daily summary did not finish", "Daily summary ran out of time at its 600s limit" or "Daily summary could not deliver its result", with a count such as "3 failures since it last worked". It does not repeat on every failed run. You hear at the first failure, the second, the fourth and the eighth, and once more when the task works again. The notice never quotes what the run produced, so open the run on the task's page to see why. A failure alert, which you can ask for, sends a notification after a number of failures in a row, and can send it to a different channel from the one the results go to, such as an ops channel.

Two rows on a task's page look worse than they are. A run that started hours late after downtime drops its message on purpose and reads not-delivered, with no notice. A run cut short by a restart reads "cron: job execution aborted before it finished", which nobody cancelled.

Where next

Step by step: schedule something or set up a trigger. A morning briefing that talks to you is a worked example.