Documentation Agent Automation

Automation

1 min read·Updated 30 Jul 2026

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.

SHELL
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.

SHELL
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

SHELL
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.