Schedule integration
Work that happens on a schedule, not on a trigger.
The Schedule integration runs automations at a time you choose: a prompt, a repository, an agent, and a time. Sweep yesterday's failing checks every weekday morning. Keep dependencies current every Monday. Draft the release notes every Friday at five. It opens a pull request when the work warrants one.
- Say when in plain terms: hourly, daily, weekdays, weekly, or a cron expression if you want one
- Runs in your timezone, so 09:00 stays 09:00 when the clocks change
- Every run is logged, including the ones skipped because the last was still going
- Start one by hand any time, without waiting for its next turn
No limit on how many scheduled automations you have. Each firing runs on a box and uses box-hours.
Scheduled automations
Runs a prompt on a schedule, whether or not the app is open
Morning CI triage
Weekdays at 09:00 (Europe/London) · sundial/api
Keep dependencies current
Every Monday at 08:00 (Europe/London) · sundial/web
Draft the release notes
Every Friday at 17:00 (Europe/London) · sundial/api
Sweep stale branchesOff
Every day at 02:00 (Europe/London) · sundial/infra
Not everything is a reaction
A GitHub automation fires because something happened. A scheduled automation fires because it is Monday. That sounds like a small distinction and it is the whole difference between automation that keeps up with you and automation that does the work nobody ever gets to.
The dependency bump nobody schedules. The flaky test sweep everyone agrees is worth doing. The release notes somebody writes on a Friday afternoon from the commit log. Each one is a prompt you could write in a minute and will not run consistently for a year.
Scheduled automations
Runs a prompt on a schedule, whether or not the app is open
Morning CI triage
Weekdays at 09:00 (Europe/London) · sundial/api
Keep dependencies current
Every Monday at 08:00 (Europe/London) · sundial/web
Draft the release notes
Every Friday at 17:00 (Europe/London) · sundial/api
Sweep stale branchesOff
Every day at 02:00 (Europe/London) · sundial/infra
A scheduled automation is five choices
The repository, the prompt, the agent and model, the run type, and the schedule. Choose a reviewable Talyn session or a cloud task. Both use the same agent, pull request, and plan rules as work you start yourself. The Schedule integration adds the clock. You find your automations under Integrations, then Schedule.
- Hourly, daily, weekdays, weekly, or a raw cron expression
- Your timezone, correctly, including across daylight saving
- Pick the agent per automation: Claude, Codex, or PostHog Code
- Choose what happens if the last run is still going: skip is the default
Missed occurrences fire once, not six times
If Talyn is down or deploying when a scheduled automation is due, it catches up (once) and then carries on from now. It does not replay every occurrence it missed, because six near-identical tasks at once is not what anybody wanted, and if you were out of box-hours it would be one run and five refusals.
Re-enabling an automation you switched off is a resume, not a backfill. It starts from the next occurrence.
The internet switch, off by default
The sandbox of a scheduled automation normally reaches its repository and its agent's API and nothing else. That is not a limitation we ran into; it is deliberate. A prompt that has just read untrusted pull request text should not have a route out to post it somewhere.
Some jobs genuinely need the web: checking an upstream changelog, reading an advisory. So internet access is a per-automation switch, off unless you turn it on, and the posture travels with the task rather than the loop, so a run that is retried later gets the setting it was created with. The choice is offered as 'Repository only' or 'Allow the internet'; you never have to think about routing tables. It is available on Talyn Fleet only.
When the subscription runs out
A scheduled run that fires at 3am and hits an exhausted monthly quota should not just fail. If your Claude subscription is spent, Talyn moves that run to your Codex subscription if you have one, and then to PostHog Code. The exhaustion is remembered, so the next scheduled run does not boot a machine to learn the same thing, and it is cleared by proof: a successful run, a fresh sign-in, or the vendor's own stated reset time.
A rate limit is treated differently and deliberately: that clears by waiting, and moving off it would spend money to avoid a short pause.
Questions, answered.
Automations in the Schedule integration. They run a prompt on a schedule instead of waiting for something to happen. Pick a repository, write what you want done, and say when (hourly, daily, weekdays, weekly, or a cron expression) and an agent runs it on its own, opening a pull request when the work warrants one.
Yes. Schedules run in your own timezone, so 09:00 daily stays 09:00 to you across daylight saving. That is the one part of scheduling nobody hand-rolls correctly, so Talyn does not.
That is a per-automation setting, and skipping is the default: the skipped occurrence is recorded in the history rather than silently dropped. It is also what makes a tight schedule self-limiting, which is why there is no minimum interval.
No. You can have as many as you want on any plan. Each firing creates a session or cloud task that runs on a box, so the cost is the box-hours its runs use.
Talyn does this for you.
Coding agents in cloud sandboxes, from the first prompt to the merged pull request, on the Claude or ChatGPT plan you already pay for. Free with 10 box-hours a month.