Flagging Stale Jira Issues with a Scheduled Automation Rule

The problem: stale work that hides in plain sight

Teams often notice that a few issues stay in “In Progress” for weeks, accumulating outdated comments and blocking metrics. Manually hunting them down is tedious and error‑prone.

Thesis: a scheduled Jira Automation rule can surface those issues automatically

By combining a scheduled trigger, a JQL query, and a comment action that uses smart values, you get a lightweight, repeatable hygiene check that runs without custom scripts.

How the rule fits together

• Trigger – “Scheduled” fires on a cron‑like schedule (e.g., every day at 09:00).
• Condition – the trigger’s JQL narrows the set to issues that match the stale criteria.
• Action – add a comment that tags the assignee and suggests an update or closure.

Smart values such as {{issue.key}}, {{issue.assignee.displayName}}, and {{now.minusDays(14)}} let the rule compute thresholds and personalize the message without hard‑coding dates.

Worked example: flagging issues inactive for two weeks

1. Navigate to Project settings → Automation → Create rule. You need the Jira Administrators or Project Administrators permission.
2. Choose the Scheduled trigger, set it to run daily at 09:00, and leave the “Repeat” field blank.
3. In the trigger configuration, paste the JQL:

   project = ABC AND status = "In Progress" AND updated <= -14d

   Verify the query first in Issue Navigator (requires Browse Projects permission) to confirm it returns only the intended stale issues.
4. Add a new condition: Advanced compare condition with the smart value {{issue.assignee}} is not empty. This prevents commenting on unassigned tickets.
5. Add an action: Comment on issue. In the comment field use:

   Hey {{issue.assignee.displayName}}, the issue {{issue.key}} has not been updated for 14 days. Please review and update its status or close it if appropriate.

6. Save the rule and give it a clear name, e.g., “Flag stale In‑Progress issues”.

Testing and debugging with the audit log

Before enabling the rule for the whole project:

• Run the rule manually from the rule details page (button “Run rule”).
• Open the Audit log tab for that execution. It lists each issue matched, any condition failures, and the comment that was posted.
• If the log shows zero matches, double‑check the JQL in Issue Navigator; if it shows errors, look for smart‑value typos (they render as blank text rather than throwing an exception).

Once the audit log shows the expected matches and comments, switch the rule from “Draft” to “Active”.

Trade‑offs and limits to keep in mind

• Execution quotas – Cloud plans enforce a monthly limit on rule runs; the exact number varies by tier and can change, so consult the current Automation limits page for your plan. Data Center has no monthly quota but consumes instance resources, so very large result sets can affect performance.
• Batch size cap – Historically a scheduled run processes a capped number of issues per execution (often cited around 100). If your JQL returns more, consider narrowing the query (e.g., add a component or priority filter) or split into multiple rules.
• Rule sprawl vs. REST API scripts – Automation rules are easy to create and maintain but are not version‑controlled or unit‑testable. For complex logic that needs branching, error handling, or reuse across projects, a script against the Jira REST API stored in a repository may be preferable.
• Branching and loops – Enabling “Trigger other rules” or using branch actions can cause unintended chains. Keep each rule single‑purpose and test the audit log for unexpected executions.

Actionable closing

1. Create a sandbox project and replicate the rule above.
2. Run it manually, inspect the audit log, and verify the comment content.
3. Adjust the JQL and smart values until the log shows exactly the issues you expect.
4. Promote the rule to your target project, enable it, and schedule a weekly check of the audit log to ensure it stays within your plan’s execution quota.
5. If you notice the rule consistently hitting the batch limit, refine the JQL or consider a REST‑API‑based hygiene job for larger data sets.