The Stale Ticket Rule That Ran Out of Budget

Read the audit log before changing anything.

Automation → Audit log, filtered to this rule and to SUP, shows which action failed per issue. Because actions run in order, a comment that landed and a transition that did not means the transition action specifically failed.

Likely causes, in order:

1. Actor permissions. The rule runs as its configured actor. SUP may use a different permission scheme in which that actor lacks Transition Issues - while still holding Add Comments, which explains the exact symptom. Resolve the actor against SUP's scheme.
2. Workflow mismatch in SUP. If SUP maps the issue type to a different workflow, or the Waiting for Info → In Progress transition carries a condition such as Only the assignee, the transition is never offered to the actor even though the name matches.
3. Validator failure. A transition screen with a required field (vendor reference, resolution) is empty on those 300 issues, so the transition is rejected.
4. Post-function failure. A post-function that sets a field the actor cannot edit will abort the transition after the comment already posted.

Fix the cause, not the symptom: give the rule a dedicated service account with explicit project permissions, or add that account to the condition's allowed group. Re-run against one SUP issue and read the audit log again before re-enabling the schedule. The unrecognised comment author is the same actor - rename the account to something agents will recognise.

The rule commented before it transitioned, so a failed transition left the issue eligible again.

Issues that stayed in Waiting for Info still matched status = "Waiting for Info" AND updated < -7d - except that a comment updates updated, which is a second bug hiding inside the first: the rule never processes issues that anyone touched recently, and processes issues it already handled as soon as the window reopens.

Two changes:

1. Reorder the actions. Transition first, comment second. If the transition fails, nothing else runs and the issue is left untouched and auditable. Re-test the ordering in a scratch project.
2. Add a guard that does not depend on updated. Create a date field Last Reminder Sent; have the rule set it, and add AND ("Last Reminder Sent" is EMPTY OR "Last Reminder Sent" < -7d) to the JQL. This makes each issue processable at most once per week regardless of what else edits it, and it stops unrelated edits from silently hiding issues from the reminder.

Do not solve this with a comment search such as comment ~ "Gentle reminder" - it is fragile the moment someone quotes the phrase in a real reply, and it scales badly at 30 projects.

1,800 issues in one daily run is the problem; the JQL and the schedule are the levers.

First, measure: open the automation usage page and the audit log and record which rules consumed the allowance. Do not guess - an unrelated runaway rule is often the real culprit.

Then reduce work per run:

• Make the JQL stable. Replace updated < -7d with the Last Reminder Sent guard from the previous task. Today the rule both misses issues that were touched and re-picks issues it already handled.
• Cut frequency. 1,200 open SUP bugs do not need a daily nudge. Weekly, or twice weekly, removes roughly 70% of the volume with no change to the support process.
• Exclude the already-handled. With the guard in place, each issue is processed once per reminder cycle instead of every day it stays open.
• Split the rule per project. A SUP-wide failure cannot then consume budget earmarked for OPS, and each audit log stays readable.
• Move one-off work out of automation. The 300 stuck issues are a data correction: run a JQL bulk change once, rather than letting a recurring rule grind at them nightly.

Finally, set an alert: add a scheduled check or watch the usage page weekly, so you learn about the ceiling before rules start failing silently in production.