Automation rules
When something happens to an issue, automatically do one or more things to it — no YAML, no scripting.
What it does#
A project can define automation rules: when something happens to an issue, automatically do one or more things to it — no YAML, no separate CI job, no scripting language to learn. Manage them from a project's Automation page.
Triggers#
| Trigger | Fires when |
|---|---|
| Issue opened | A new issue is created in the project. |
| Issue closed | An issue's state changes to Closed. |
| Issue reopened | A previously-closed issue's state changes away from Closed. |
| Label added | A specific label (you choose which, per rule) is attached to an issue — whether at creation or afterward. |
Actions#
A single rule can chain multiple actions, applied in order: add a label, remove a label, assign to a specific person, set the milestone, set the status (Open / In progress / Closed), or post a comment with fixed text. A rule that watches for a bug label, for example, can add needs-triage, move the issue to In progress, and post a comment asking for a reproduction case — all from one label being applied, with nothing else involved.
Execution model and safety#
Rules run synchronously, server-side, at the exact moment their trigger occurs — by the time an API call that opened or labeled an issue returns, every matching rule has already run. Actions are applied as direct writes rather than by replaying the same code path a person's action would take, which is what guarantees an automated action can never itself re-trigger another rule: there is no chain reaction to reason about, no risk of two rules quietly looping off each other. A broken or misconfigured rule (say, referencing a label that was since deleted) fails safely and is logged — it never blocks or breaks the issue update that triggered it.
Automated changes are attributed to whoever created the rule (visible in the issue's audit history), and disabling a rule — a single toggle, no need to delete it — stops it from firing while keeping its configuration intact. Only project maintainers can create, edit, or delete rules; any project member can see which rules are active.