Concepts

Automations

An automation is a saved prompt in a Project with triggers that say when it runs: a GitHub event, a schedule, a webhook call or a Linear issue change.

View .md

An automation starts the same run a person starts from the console, with nobody at the keyboard. It is a saved prompt in a Project plus any number of triggers. When a trigger fires, Rush starts a run with that prompt and puts the event that fired it after the prompt, marked as third-party data. The saved prompt is the only instruction.

You create and edit automations in the console, on the Project's page. Anyone who can see the Project can also run one now, with no trigger.

05The same event twice: deduped

kind: githubpull_request.openedkind: schedulecron: 0 2 * * *kind: webhookPOST, signedkind: linearlinear.issue.labeledAUTOMATIONprompt + triggersseen this onerun startedstartedrun startedstartedrun startedstartedrun startedstartedthe same event againstatus: deduped · no new run
Scene. Each fire of a trigger starts one run with the automation's prompt. A repeated delivery is deduplicated; a busy or rate-limited automation skips with its reason.

What an automation holds

  • A prompt, up to 20,000 characters.
  • A saved agent of yours, or none to use the Project's default harness. See Saved agents.
  • Read only. Its runs can read the repository and comment, but not push.
  • Max runs per hour, 1 to 30, shared by all its triggers and Run now.
  • A session to wake, optionally. Instead of starting a run, each fire sends the prompt as a follow-up to one resumable session in the Project, which keeps its machine and memory between fires. A fire that lands mid-turn is skipped.

An automation runs as the member who last changed what it does. If an admin edits another member's prompt, saved agent or triggers, the runs become the admin's. Nobody can make a run act as someone else.

Trigger kinds

Kind Fires on Settings
github issue_comment.mention, pull_request_review_comment.mention, pull_request.opened, pull_request.synchronize, pull_request.closed.merged, pull_request.labeled, issues.opened, issues.labeled, check_suite.failure, workflow_run.failure branch_patterns (globs on a pull request's base branch), labels (any of), authors (GitHub logins)
schedule A time slot cron (five fields, at most hourly) or every (10m, 30m, 1h, 1d), and timezone (IANA, UTC by default)
webhook A POST to the trigger's URL None. The body, up to 64 KB, becomes the event text
linear linear.issue.state_changed, linear.issue.labeled states (state name to plan or exec), labels, teams (team keys; empty means every public team)

GitHub

Only work by a repository OWNER, MEMBER or COLLABORATOR fires a trigger. Pull requests from forks and CI runs from forks never fire, and neither do bot senders.

Schedule

every is stored as its cron, and 1d means midnight in the trigger's time zone. 10m and 30m are allowed only on an automation that wakes a session. Turning an automation back on moves each schedule to its next slot rather than firing the slots it missed.

Webhook

The console shows the trigger's secret once, when you create the trigger or rotate its secret. Store it then. Call the trigger with Authorization: Bearer <secret>, and send an Idempotency-Key header so a retry starts nothing new. An unknown trigger and a wrong secret both answer 401.

Linear

A Linear trigger needs a Linear connection for the automation's runner. It fires when an issue moves into one of states or gains one of labels, and only when the person who made the change is in your Rush org; changes made by an app integration never fire. A state in plan mode starts a read-only run that posts its plan as a comment on the issue. exec starts an ordinary run. See Linear label to PR.

Fire outcomes

Every fire has an outcome. A webhook call answers 202 with it:

status Meaning
started A run started. execution_id names it, or the session it woke.
queued A run was created and waits for a run slot.
deduped The same event already started a run, such as a redelivery or a retried slot.
skipped Nothing started. reason says why.

A reason is one of disabled (the automation is off), paused (the Project is paused), rate_limited (the hourly cap is reached), not_member (the runner left the org), project_gone, org_deleted, or busy (a wake whose session was mid-turn).

A GitHub event that matches no enabled automation leaves no record. To find out why an automation did not fire, check its triggers' filters and the delivery history on GitHub.