Automation Loop: Comment-Triggered Rule Re-fires Itself
An automation rule in Jira Cloud is configured as: Trigger = "Issue commented"; Condition = comment body contains /status; Action = add comment "Status acknowledged by bot"; then transition the issue to "Waiting for Customer". Within an hour the team sees 400+ bot comments on a single issue, and the issue ping-pongs between In Progress and Waiting for Customer. A second rule, Trigger = "Field value changed" on Status, sends a Slack-style webhook. The webhook fires hundreds of times. The team also has a rule that comments on issues when a linked issue is resolved. Rule actor is a service account with full project admin rights.
1. Explain the loop mechanics and identify which rule(s) are re-triggering.
Read the worked answer
The loop is caused by the bot's own comment satisfying the trigger condition of the same rule. Sequence:
- A human comments
/status→ rule fires. - The bot adds "Status acknowledged by bot" - this is a new comment event. The rule's condition checks comment body contains
/status. The bot comment does not contain/status, so the comment rule itself should not re-fire on that comment - unless the condition is actually evaluating the issue's comments or the trigger is "Issue updated" rather than "Issue commented." The 400 comments strongly suggest the trigger is broader than intended (e.g., "Issue updated" or a condition that matches any comment). The first diagnostic is to confirm the exact trigger and condition scope. - The transition to Waiting for Customer fires the second rule (Status changed) → webhook. If any downstream action (webhook response, or a rule that comments) changes the issue again, the status rule re-fires.
The ping-pong between In Progress and Waiting for Customer indicates a second transition path moving it back - likely the linked-issue rule or a workflow post function - creating a two-state oscillation. The webhook count confirms the status rule is firing on every oscillation.
Root causes to name: (a) bot actions generating events that satisfy triggers; (b) no guard against the actor being the automation service account; (c) an oscillating transition pair with no terminal condition.
2. Design a durable fix that stops the loop without disabling legitimate notifications.
Read the worked answer
Apply layered guards - defense in depth, because any single guard can be bypassed:
- Actor guard (primary): add a condition
User is not the automation service account(or check{{initiator.accountId}}) at the top of each rule. This prevents the bot's own events from re-triggering rules. This is the single most effective fix. - Narrow the trigger: change "Issue commented" rules to trigger only on comments by humans, and ensure the condition inspects the triggering comment, not all issue comments. If the trigger was "Issue updated," switch to the specific "Issue commented" trigger.
- Idempotency guard: before adding the bot comment, check whether an identical bot comment already exists (e.g., a condition on a label or a custom field "bot-acknowledged"). Set the flag in the same rule so a second pass short-circuits.
- Break the oscillation: add a condition to the status rule that it only fires on specific transitions (e.g., only when moving into Waiting for Customer from In Progress), and remove any rule/post function that moves it back automatically. A status change rule should not itself change status.
- Rate-limit the webhook: add a throttle or a "only if changed in last N minutes" guard, and point the webhook at an endpoint that de-duplicates.
Finally, review the service account: it should have only the permissions the rules need, not full project admin. Over-privileged actors make loops more damaging. Test the fix on a staging copy with a single issue before enabling in production, and check the rule audit log to confirm no further firings.