How to Track and Monitor JIRA Issue Limits Using JIRA Automation

[Martin Spernjak]

Hi Atlassian Community,

I wanted to share some insights on how to monitor Jira issue limits, according to the [Upcoming changes: Introducing per issue limits for list fields in Jira Issues] on Cloud.

This recent change prompted me to explore how to be notified (as an admin) when a certain issue is approaching one of its limits in comments, attachments, issue links, or worklogs.

There is also a feature request [JSWCLOUD-26509] for this in the Atlassian backlog, so this is a certain workaround for it.

In parallel, there have been many inquiries in the community about monitoring and tracking issues that are approaching or exceeding their limits. To address this, Atlassian has developed an API endpoint, the [Get Issue Limit Report API], that returns a list of issues nearing one of the limits (issuelinks/comments/worklogs/attachments) or those that have already exceeded them.

The mentioned endpoint is already a great help and will very likely serve as the foundation for any automation of activities related to limits, but here I want to show how to be notified when certain issues are approaching their limits, relying exclusively on Jira's native functionalities such as Jira automation.

There are certainly other solutions as well, and if you have any suggestions or alternative approaches, feel free to share.

Suggested Automation Rule

This Jira Automation rule runs on a daily schedule, sending a web request to a specified API endpoint. It then evaluates the response to identify any tickets that are approaching their limits. If any tickets are found to be nearing their thresholds, the rule triggers the appropriate actions, such as sending notifications or alerts.

Rule setup

Scope : Global

• Trigger : Scheduled to run once per workday.

• Actions

  • Send web request

    • Web request URL : https://your-domain.atlassian.net/rest/api/3/issue/limit/report?isReturningKeys=true

      • It's important that you use the query parameter isReturningKeys to return issue keys instead of issue IDs in the response.

    • HTTP method : GET

    • Web request body: Custom data

      • Required for querying issues approaching limits. Optional for querying issues breaching limits. Accepted fields are: comment, worklog, attachment, remoteIssueLinks, and issuelinks.

        • Example: {"issuesApproachingLimitParams": {"comment": 4500, "attachment": 1800}}

          1. Note that some values have a threshold range, so be cautious with the values to avoid 'Bad Request'
             

        • In this example, we will establish a comment threshold of 4,300 comments. This means that all issues with a comment count exceeding this number will be included in our response
    • Mark “Delay execution of subsequent rule actions until we've received a response for this web request”
    •  Headers:

      • Add Header with Authorization Basic "<EMAIL>:<API_TOKEN>" encoded to base64

        • To create a token, visit Manage API tokens for your Atlassian account | Atlassian Support

        • Encode token to base64

          • You can use terminal command: echo -n mail@mail.com:token | base64

          • Paste new generated value into header: Basic encoded_token

      • Add Header with Content-Type / Value : application/json
        

  • Add values to audit log (optional)

    • If you want to log response

  • Conditions

    • There is plenty of room for comparison here, and the most convenient combination seems to be a mix of regex and smart values.
      

    • The regular expression

      ^(?!.*\\{\\}).+

      is designed to verify whether there are any values present in the ApproachingLimit response, and as we are having issues with comments count bigger than our threshold (4300), this will be caught with this regex.
      
      
      In this scenario, the process involves checking for any values related to limits. If values are present, an email is sent to the admin. If there are no values, a message is logged indicating that there are no issues approaching the limit.

Complete rule

Execution logs

Execution log when approaching the limit

Execution log when there is no approach to the limit

[Bill Sheboy]

Hi @Tomislav Tobijas _Koios_ 

Some scenarios / anti-patterns where I recall community posts where the limits could be reached include:

• "The never ending story"
  • Teams use an Epic as a "bucket" for things like "Waiting for review", "Prod Support", etc. and so the comments, etc. churn forever-ish
  • Teams use a single issue to log and roll-up "all work time" by person, and so the logs run forever-ish
  • Messy backlog where issues linger for years without being refined, completed, or cancelled.  (For examples, look at the Atlassian public backlog with decades of comments ;^)
• Work-arounds to roll-up worklogs
  • Automation rules, or other scripting, repeatedly churns child / grandchild issue logs up to the parent, recalculating them over and over
• Substitute for document retention system
  • Storing many, possibly unrelated, documents as attachments in a single issue
• Using comments for journaling?  (I made this one up :^)

Kind regards,
Bill

[Tomislav Tobijas _Koios_]

Yeah, I thought that something like everything you've mentioned is actually the case. I've also seen a couple of cases where everyone just logs work on one issue for a couple of years and then it reached worklog limit.
We've then explained some pros of dividing things into multiple issues and things started to roll. 

I potentially see some far-fetched edge cases where these limits could be reached but that's still something you probably don't want to do. Like these for example:

(For examples, look at the Atlassian public backlog with decades of comments ;^) 😅

Anyway, I just wanted to see if there are any scenarios where you would actually want to use that one issue instead of splitting it up (and therefore potentially reaching all those mentioned limits).

Thanks for the insights guys!

[Martin Spernjak]

Hi @Tomislav Tobijas _Koios_ ,

Certainly, there are more scenarios to consider, but I will focus on the two most common ones I have encountered: worklogs and issue links.

In the first case, there are tasks where team members log time during ceremonies. If we have a team of 5-7 members who log time for daily meetings or other team ceremonies, this cumulative logging can reach significant levels over a period of one to two years.

The second case involves issue links, where a master ticket represents a business project, for instance, and tickets from multiple Jira projects are linked to it.

In any case, if such situations arise, it is highly likely that we are approaching things incorrectly, especially in case two. These practices should be avoided from the start.

Therefore, we must also take on a consultative role to guide users in adopting the system correctly, ensuring they use it in the most optimal way and then those situations will not appear.

[Martin Maida]

Great content!

[Tomislav Tobijas _Koios_]

Great content @Martin Spernjak !

One question though (for everyone else too) - what would be the cases where you would even be close to these limits? As someone said in the official announcement article for these upcoming changes, these limitations are quite reasonable as everything beyond (and IMO everything even close) wouldn't be considered best practices for using the tools.