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

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.

_Figure: triggers fire, on the page at /docs/concepts/automations._
## 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](/docs/concepts/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](/docs/use-cases/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.