Automation
Anything you can run once, you can run on a schedule or in response to an event. Automations are stored server-side, so they run whether or not your shell is open.
Schedules
Cron syntax, evaluated in the project's timezone.
arble schedule create nightly-triage \
--cron "0 7 * * 1-5" \
--task "Summarize failing CI runs from the last 24 hours and post to #eng-alerts"
Triggers
Event-driven rather than time-driven. A trigger fires on a webhook or a connector event.
arble triggers create pr-review \
--on github.pull_request.opened \
--max-retries 3 \
--task "Review the diff against @acme/release-checklist and comment"
Queues
Jobs in the same queue run serially; different queues run in parallel. Use one queue per resource that cannot tolerate concurrent writes — and a separate queue from interactive work, so a nightly batch does not starve users.
Retries
Failed jobs retry with exponential backoff, bounded by --max-retries. Only errors the
tool marked retryable are retried. A permission denial is never retried, because retrying cannot
change the outcome.
Inspecting runs
arble jobs ls
arble jobs logs job_4hVn2Qs
Prefer arble schedule to a cron entry. Scheduled runs get
retries, queueing and job logs; a crontab line gets none of those.