Browse documentation

What starts a run

Distinguish manual actions, recurring eligibility windows, commit-driven checks, and provider triggers.

Manual actions

Run now, Re-run now, and finding-level Autofix controls are explicit requests scoped to the repository and action you selected. A manual request still passes connection, concurrency, duplicate, source-context, account, and runbook-safety checks. It cannot override missing provider permissions or expand the published action’s scope.

Audit schedules

An enabled recurring audit becomes eligible according to its cadence, selected days or date, time, and timezone. Guard checks whether useful newer repository state exists and whether the same audit is already active. An unchanged repository may keep its current result instead of producing a duplicate report.

The schedule is attached to one audit metric. Other audits need their own recurring settings.

Improvement schedules

An Improvement Job becomes eligible according to its configured frequency and timing. The job carries its improvement kind, repository, Autofix variant, and write behavior. Every run revalidates the current default branch and provider queue; enabling a schedule does not preapprove a particular patch.

Backlog or repository-inactivity state can pause recurring work. Manual controls and completed history remain separate from that schedule state.

Provider events

Code review recognizes supported GitHub pull-request and issue-comment events and GitLab merge-request and note events. A newly opened non-draft review request can take the automatic review route. A mention can request a default review, a review focused by the user’s question, or a safe read-only project answer.

Draft requests do not take the normal automatic-review route until they meet the trigger contract. Ambiguous repository or request identifiers are not guessed.

Active-testing jobs

Auto-pentest also needs exactly one website from the current task’s Linked websites block and current authorization for active testing. The schedule or manual action does not authorize adjacent hosts. Without one unambiguous allowed target, the run records a target-unavailable outcome and performs no active external probing.

Why a trigger may not run

A request can remain inactive because the repository is disconnected, no newer commit exists, equivalent work is running or already open, the schedule is paused, the backlog is too large, the account cannot start more work, the provider target is ambiguous, or a required consent or source context is missing. Use the action’s report or disabled-state explanation before retrying.