Automations
Configure recurring or GitHub-triggered work and interpret PR decisions separately from execution runs.
Use automations for work that should start from a repeatable schedule or a repository event instead of a person opening a session. Choose a narrow goal, the repository and base branch, the identity and model, and one or more triggers.
Choose a trigger
An automation can run on a schedule, a supported integration event, or GitHub pull-request activity. GitHub triggers include PR creation and updates, completed checks, review submissions, inline review comments, and issue comments on a PR.
Scheduled automations use a sentence-style editor. Choose Daily, Weekdays, Weekly, or Monthly, then select the local run time and IANA time zone. Weekly schedules can run on more than one day, such as Monday and Thursday. The editor shows the next concrete run before the schedule is saved.
Use an interval for elapsed-time work such as every six hours. Calendar schedules such as every Monday stay anchored to the selected time zone, including across daylight-saving changes. Monthly schedules on the 29th, 30th, or 31st skip months that do not contain that date. Existing advanced cron schedules remain editable without being converted to a simpler schedule.
Filters such as base branch, author, path, feedback type, and review state reduce unnecessary runs. Keep filters as specific as the workflow allows; an automation that reacts to every comment and every check can evaluate the same revision several times.
For GitHub triggers, PR labels matches a PR with any listed label. Exclude PR labels skips a PR with any listed label, even when it also matches PR labels. Label matching is case-insensitive. If a GitHub event does not include PR labels, 143 looks them up before deciding whether to run; if the lookup fails, an automation with either label filter does not run.
Keep one conversation per pull request
Select Continue one session per pull request with a PR trigger and Do not publish. Each event continues the PR's session. Most external-write tools are unavailable because a crashed turn can execute again.
An organization admin can enable Resumable automation actions for any automation, including scheduled and manual runs. Choose Configure actions, select the operations the goal needs, and fill in only their destinations. For example, a daily Slack report needs only a Slack channel; it does not need GitHub or Notion configuration. The capability is off by default and is separate from External comments and Slack notifications.
Supported actions add a GitHub PR label, request a team's review, comment on a PR, create a Notion page in a configured data source, or send a Slack message. Notion configuration lists allowed property names and types, with exactly one title property. The connected provider must permit the chosen action and destination. Enabling or changing this grant requires an organization admin; members can disable it.
Use the resumable action commands in the goal. Give each logical workflow a stable operation key and each step a stable action key. Later runs can inspect receipts and resume unfinished steps with the same keys. Separate scheduled occurrences use new operation keys. Confirmed actions are not repeated; uncertain sends require operator reconciliation. Finishing an agent run does not prove all intended actions completed.
Configuration changes apply to future runs and block unfinished actions using the old configuration. Completed receipts remain available. GitHub actions require the current PR head. Slack and Notion can omit this precondition in every run mode, including continuous sessions, so independent steps can resume after a push or run during a subscribed merge-event turn. Supply a PR/head precondition for commit-specific content; it stays enforced on resume.
Read PR decisions
For GitHub-triggered review work, the default history view shows one decision for each pull-request revision. The summary separates:
- PRs: distinct pull requests evaluated.
- Revisions: distinct PR head revisions evaluated.
- Attempts: raw automation executions, including retries or repeated events for the same revision.
Each decision identifies the repository, PR number, revision SHA when available, and the number of evaluation attempts. Open the PR directly from the decision card.
Understand outcome labels
Review outcomes and execution status answer different questions:
| Label | Meaning |
|---|---|
| Passed | The automation reported that the evaluated revision passed its review criteria. |
| Changes requested | The automation found blocking changes and reported a rejection-style review outcome. |
| Advisory | The automation reported non-blocking guidance. |
| Not applicable | The automation determined that its review did not apply to this revision. |
| Evaluating | The latest run for the revision is still pending or running. |
| Execution failed | The automation failed before it reported a review decision. |
| Outcome not reported | The run finished, but no structured decision was recorded. Do not infer that the PR passed. |
When an outcome includes a GitHub review or comment, use the action link to inspect the exact external result. Some older outcomes are marked Inferred from legacy summary; these were recovered only from a strict historical summary format rather than reported through the structured outcome contract.
For agents
A completed run means the automation infrastructure finished. It does not, by itself, mean the pull request passed review.
Debug raw runs
Switch to Raw runs when you need every execution attempt, session failure details, or retry history. This view is intentionally operational: statuses such as completed, failed, skipped, and no-op describe execution, not the business decision about a PR.
If structured decisions are not available on a deployment yet, the page falls back to execution history and displays this distinction inline.