Cronjobs & Automation

Band includes a built-in cronjob scheduler that lets you run coding agent tasks on a recurring schedule. Cronjobs are defined with standard cron expressions and can be scoped to either a project or a specific workspace. When a cronjob fires, it submits a task to the configured coding agent just as if you had typed the prompt manually.

Creating a Cronjob

From the Band dashboard, navigate to the Cronjobs section and click Create Cronjob. Fill in the following fields:

• Name — A human-readable name for the job (e.g., "Daily dependency check").
• Prompt — The prompt sent to the coding agent when the job fires.
• Cron Expression — A 5-field cron expression defining the schedule.
• Scope — Either "project" or "workspace".
• Enabled — Whether the job is active.

Cron Expression Syntax

Band uses standard 5-field cron expressions. Each field is separated by a space:

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-7, 0 and 7 are Sunday)
│ │ │ │ │
* * * * *

Common examples:

Project-Scoped vs Workspace-Scoped Jobs

Project-Scoped

A project-scoped cronjob runs on the project's default branch. Band looks up the project by name and submits the task to the workspace corresponding to the default branch. This is ideal for recurring tasks that should always run against the main codebase, such as dependency updates or code quality checks.

Workspace-Scoped

A workspace-scoped cronjob targets a specific workspace (project + branch combination). You select the workspace when creating the job. This is useful for branch-specific automation, such as running checks on a long-lived feature branch.

Enable and Disable

Each cronjob has an enabled toggle. When disabled, the cron schedule is stopped and the job will not fire. You can re-enable it at any time without recreating it. Disabling a job does not affect any currently running tasks that were triggered by it.

Manual Triggering

You can manually trigger any cronjob from the dashboard regardless of its schedule. This submits the job's prompt as a task immediately. Manual triggers respect the same conflict rules as scheduled runs — if a task is already running in the target workspace, the trigger is skipped.

Conflict Handling

When a cronjob fires and a task is already running in the target workspace, the execution is skipped and recorded with a "skipped" status. Band does not queue cronjob prompts — skipped executions are simply noted and the next scheduled run will attempt again. This prevents cronjobs from piling up during long-running tasks.

Execution History

Each cronjob records its last run time and status. The possible statuses are:

• completed — The task was submitted successfully.
• failed — The task submission failed (e.g., workspace not found).
• skipped — A task was already running in the target workspace.

Use Cases

• Automated code reviews. Schedule a daily prompt like "Review all files changed in the last 24 hours and report any issues."
• Dependency updates. Run "Check for outdated dependencies and create a PR with updates" weekly.
• Daily reports. Generate "Summarize the git log from the last 24 hours and post a summary" every morning.
• Test suite monitoring. Schedule "Run the test suite and report any failures" every few hours.
• Documentation freshness. Prompt "Check if any public API changes are missing documentation updates" weekly.