Schedules and run history
On this page
A scheduled automation can ask an agent to do recurring work, such as checking your repository every weekday morning. Its run history records each attempt and links to agent threads for runs that start successfully.
Set the schedule and capacity behavior
- Open the automation in your project's Automations section and choose the Schedule trigger. If you haven't created one yet, start with Create an automation.
- Set the repeat interval in hours, days, weeks, or months. Choose the first run time, time zone, start date, and applicable weekday or day of the month.
- Review the options for what to do when your awake devbox limit is reached, that is, when as many devboxes as your plan allows are already awake. You can allow boxes.dev to sleep an idle devbox to make room. Scheduled runs can also wait and retry while capacity is full; the retry interval and time window appear in the settings.
- Choose Create for a draft or Save changes for an existing automation. Test with Run now, then choose Activate if the automation is paused.
- Check the next scheduled run shown beside the automation in the thread list.
A scheduled run can be skipped if another manual or scheduled run of the same automation is still starting or active, and Run now can be rejected in the same situation. API requests, Slack threads, and Linear Agent Sessions are independent events, so they can start parallel runs, subject to the awake devbox limit.
API automations also offer the option to sleep an idle devbox. These capacity options only help when the blocker is the awake devbox limit; they don't bypass billing limits or fix other startup failures. A paused automation won't accept normal triggers, and an errored automation needs its reported problem resolved before it can run.
Read run history
For runs grouped under an automation, expand the automation in the thread list and choose Load more runs to see older entries. To see every recorded run, choose View run history from the automation's actions menu.
A run can be starting, ready, skipped, or failed. Select a run to inspect its status, timing, trigger, and details for a support report, or open its thread to read the agent's response. Run status records the launch, not the agent's result: Ready means that the run's thread exists and can be opened, and the agent may still be working, so check the thread itself to see whether it has finished. Failed and skipped entries include a reason in the thread list.
Each run keeps the prompt, thread title, agent, model, reasoning, and speed settings it started with, and records whether its prompt came from the saved automation, an API request, or Slack or Linear. Later edits to the automation won't change this record. Older runs created before these details were recorded show them as unavailable.
The automation's detail pane also shows its last trigger time, last successful run time, and run count. If a run's devbox contains several threads, expand the devbox beneath the run to open them individually. A run's devbox can also be moved into a project folder from its Move to menu; the folder assignment stays in place if you change Where runs appear.
Choose optional cleanup
If recurring runs leave you with devboxes you no longer need, automatic cleanup can archive each finished run's conversation and destroy its devbox. Cleanup is available for Schedule and API automations whose runs appear Under this automation, including tests started with Run now. Manual-only, Slack, Linear, and main-list runs are not eligible.
Open Devbox cleanup in the automation's settings. Cleanup timing defaults to Never, so saving the automation makes nothing eligible until you choose a timing. Choose After the run finishes, After days without activity, or After newer runs finish, and enter the number of days or runs where applicable. Whichever timing you choose, cleanup includes a 30-minute grace period after the run finishes.
Cleanup will archive the conversation and permanently destroy the devbox's files. Commit and push code, or download artifacts you need to keep.
By default, cleanup will keep devboxes with uncommitted changes, unpushed commits, or a follow-up after the first agent response. You can allow cleanup despite those conditions in the policy settings. Pinned threads, threads that need input or were interrupted, and devboxes with another thread are always kept. Once a safeguard keeps a devbox, removing the condition later won't make it eligible again; for example, a devbox kept for unpushed commits stays kept even after you push them.
Choose Save changes to apply the policy to future runs. Older eligible runs stay untouched until you choose Review existing, inspect the counts, and explicitly apply the policy to them.
Archived threads remain readable under the automation without a running devbox. To continue a conversation, choose Restore thread and a new devbox or, if your project has one, its Template box. Restoring the thread won't recover the destroyed devbox's files.
If boxes.dev wakes a sleeping devbox solely for cleanup, that time won't use your box-hours. An already-running devbox uses normal box-hours, as does a devbox you connect to after cleanup wakes it.
If cleanup repeatedly cannot access or destroy a devbox, boxes.dev stops after eight failed attempts and the run will show Cleanup needs attention. While the run needs attention, its thread and devbox remain available. Open the run, inspect the problem, and choose Wake and retry cleanup or Keep devbox; keeping the devbox means boxes.dev won't try to clean up that run again.
Send results to Slack
To receive results without checking the workbench, open Slack output in a saved Manual, Schedule, or API automation. Your team needs a working Slack connection. Choose a channel or a DM with someone who has linked their Slack account to boxes.dev. Select which events to send (final output, a request for input, or a failed run), then choose Add destination.
The destination will receive events from the run's initial agent response only. If you later continue the thread in boxes.dev, those replies will stay in the boxes.dev thread. Slack and Linear automations reply in their originating conversations and don't use this panel.