Upcoming changes: Introducing per issue limits for list fields in Jira Issues

[#1]

August 2024 Update: 

We are pleased to announce the latest updates on increasing the worklog limits to 10K. The enforcement of these limits will happen by 2nd December'24. If you have issues over 10K limit, we suggest checking out the latest updates and provide your feedback on the solutions from Atlassian and Tempo in this new community post: Introducing-Bulk-Move-and-Bulk-Delete-Worklog-APIs 

---

July 2024 Update:

We are building relevant APIs and working alongside Tempo to develop solutions as  mitigations for worklog limits. 

Expect a new update soon in August 2024 on these solutions. 

Do note, that we plan on providing a period between the release of these solutions and enforcement of limits. The date of which would be communicated in the update above. 

---

May 2024 Update: 

Thank you for your patience thus far. We are committed to improving the Worklogs solution in Jira and are also working closely with Tempo to accomplish this objective.

As a result, we will release the next update in July 2024.

This means the enforcement of the Worklog limits would not come in until atleast August 2024. 

---

April 2024 Update:

Admins can get the list of issue IDs that are approaching the limit or over the limit using the Get Issue Limit Report API.

The issue IDs returned are based on worklog data in Jira. Please refer to Tempo documentation for details on sync caveats around Tempo originating worklogs.  

---

March 2024 Update:

Thanks everyone for your patience so far. We had made the initial change log notice and community post ~6 months ago, hoping it would provide sufficient time to update workflows. However, we acknowledge the feedback indicating that there could have been better visibility, specifically for the worklog limits. The intention was never to provide a mere 2 weeks' notice, and we recognise that this represents a significant change management process for many of our customers.
Therefore, we will delay the enforcement of worklog limits until July 2024 to accommodate additional time to update existing workflows required for worklog limits. For further details on specific dates, please refer to "Worklogs Limit Rollout" section below.

The limits for all other issue entities will rollout as per the original timelines.

In addition, we are actively working on an API that will allow admins to query issue IDs that are either approaching the limit or already over the limit, which will be released in April 2024. We will share further updates around this on this community post. 

---

January 2024 Update:

Thanks everyone for sharing your valuable feedback. A quick update on how we are tracking for this change - we want to ensure a smooth transition for our customers, so based on customer feedback so far, we will be pausing the transformation of existing issues that are over the limit.

We will begin the rollout for enforcement of per issue limits for list fields in the last week of March 2024, but all existing issues over the limit will be retained as is. We will provide additional 3 months notice before any transformations are rolled out.

---

As part of our ongoing efforts to improve the performance and reliability of Jira Cloud, we will be introducing limits on issue data.

This will enhance the reliability and efficiency of our platform to provide users with a more stable experience.

New Limits

Comments are limited to 5000 per issue.

Worklogs are limited to 5000 per issue.

Attachments are limited to 2000 per issue.

Linked issues are limited to 2000 per issue. This does not include child issues.

Remote links are limited to 2000 per issue. This includes:

• web links

• Confluence pages

• links to an external issue on a different Jira instance

• links to other Atlassian products

What happens when an issue exceeds the limit

Once a limit has been reached, you won’t be able to add more of that type of data to the issue. Users will receive an error to inform them that they have reached the limit.

Impact to existing issues that are over the limit

This won’t affect existing data for issues that are currently over the limit. But enforcement of limits will still apply for any new issue data being created on existing issues.

After considering all your feedback, we’ve decided to pause the transformation of current issues that exceed the limit for now. This means existing issue data that’s already over the limit will not be converted into another format to ensure it complies with the limit.

There are no set dates for when the transformation will resume. But we’ll give advance noticed through community posts and emails when we do, including how the transformation will be carried out.

Check which issues are about to hit the limits

Using the Get Issue Limit Report API, admins can get the list of issue IDs that are approaching the limit or over the limit. 

The issue IDs returned are based on worklog data in Jira. Please refer to Tempo documentation for details on sync caveats around Tempo originating worklogs. 

Impact to migrating issues that are over the limit

Migrations assessments will flag issues that are over the limit. Since transformation of issues over the limit is paused for now, there will be no automatic transformation of issue data during migration. But enforcement of limits will still apply for new entities after migration.

Impact to APIs

Impacted backend APIs will throw a `413 Content Too Large` response code when limit is exceeded.
For more details, please refer to changelog CHANGE-1133.

Workarounds for using a single issues to track all worklogs

We understand that the use case of using a single Jira issue to track worklogs indefinitely is a convenient practice, but it is not a best practice and optimal usage pattern. Continually adding worklogs to a single issue may lead to performance and reliability problems as the size of data grows. 

A suggested workaround for this scenario would be to set up an automated workflow to create a new issue periodically (eg: every quarter) for adding worklogs. The previous and next quarters' issues can be linked for easy reference and would help maintain a manageable size for each issue to ensure the stability of the platform.

Worklogs Limits Rollout

While limits for all other issue entities will rollout as per the original timelines, we will delay the enforcement of worklog limits until July 2024. The rollout for worklog limits will be a staggered rollout across tenants based on the respective editions.

• Free and Standard: July 8 to July 12

• Premium: July 15 to July 19

• Enterprise: July 22 to July 26

The rollout will be staggered over a week to accomodate a gradual release of changes to each customer cohort. We recommend for the workflows to be updated prior to the start of the corresponding week.

Contact

If you have any questions or feedback about this change, please comment in the section below. We’d love to hear how we can help you.

Thank you in advance for your understanding and support as we work to provide you with better and more reliable experiences on Jira!

[Dave Mathijs]

These limits sound reasonable, more is not best practice in my opinion.

[Nena Kruljac]

1. Does this mean that every issue can have 5000 comments / worklogs, 2000 attachments / issue links / remote issue link?

2. Is there a way to quickly find issues that would exceed these limits?

[Shiraine Liu]

Hi Nena,

1. Yes, with the new limits, every issue can have up to the maximum limit set for each of the fields (5000 for comments and worklogs; 2000 for attachments, issue links and remote issue links).

2. Unfortunately, at the moment, there isn’t a quick way to find which issues would exceed these limits. When we roll out the changes, relevant error messages will be provided to the user in the Issue View UI and API responses when the issue limits would be exceeded. Please refer to the changelog for more details around these https://developer.atlassian.com/changelog/#CHANGE-1133

[Andrew Morin]

This should roll over at the limits as opposed to stop allowing entries. is that the expected behavior for these limitations?

[Shiraine Liu]

Hi Andrew,

Once the changes are rolled out, users won't be allowed to add a new entry to an issue if that would result in the limit being exceeded. 
Eg: The issue already contains 5000 comments. Trying to add a new entry would give the user an error saying the limit for maximum comments in an issue has been reached. 

[Roman Fominych]

Hello team! 

In the current article there is no mention that updates of worklogs will not be possible if the limit is reached. On the other hand https://developer.atlassian.com/changelog/#CHANGE-1133 is claiming that worklog updates will not be possible when limit is reached. 

Could you please clarify where is the correct information about worklog updates when issue has hit the limit?

[Konstantinos Karamitros]

1. Just to clarify the "5000 for comments and worklogs": An issue can have 5000 comments AND 5000 worklogs? 5000 is NOT shared between the 2. Same for the attachments, issue links anre remote issue links, right?
2. Let's say existing issue that contains 5500 worklogs. I see that "Existing issues with field data over the limit will be retained as is", based on that those remain unchanged and we will not be able to add more fine. And no worklogs are getting deleted and we can still parse them using the API, as we did. The only issue is if we try to ADD some new worklog, right?

3. Since Atlassian does not have a way to bulk worklog import, we use JiraAssistant plugin to add the worklogs to Jira. Of course, we cannot rely on that plugin to handle the situation, so we need some way to check which issues are close to the limits (e.g. which issues have >4500 worklogs), so we act accordingly (create a new issue an dinform people to use that instead or whatever).

If "there isn’t a quick way to find which issues would exceed these limits" and "When we roll out the changes, relevant error messages will be provided to the user in the Issue View UI and API responses when the issue limits would be exceeded.", how shall we respond to that?

We need a way BEFORE the limits start applying (last week of march).

There is no suitable api call or even better a suitable jql query to return the issues that have >{# of worklogs} etc.?

The only way to monitor the data is to use the api, get all the Issue IDs and for each one get all the worklogs???

[Antoine _Klee Group_]

Hi @Shiraine Liu 

Do we have some analysis tools?

One of our issues in our Jira instance is concerned by those limits. Do we have a solution to audit the instance and find issues which limits are close to the limits?

Best,

[Shiraine Liu]

Hi @Roman Fominych Updates of existing worklogs will still be possible when the issue has reached the limit. The changelog has been updated with the correct information.  

[Shiraine Liu]

Hi @Konstantinos Karamitros Adding responses below

1. Yes - the limits are per issue and per entity. So the same issue can have 5000 comments AND 5000 worklogs.
2. That's correct. With this change, existing issues which are over the limit will remain unchanged. No worklogs will be deleted. Initially, we did plan for transformation of data for existing issues over the limit but that has been paused based on community feedback. There are no set dates for when the transformation will resume, but we’ll give advance noticed through community posts, including details of how the transformation (if any) will be carried out.
3. To prepare for the 31st March rollout, admins will receive emails in the first two weeks of March to let them know which sites and issues are either approaching the limit or already over the limit. 
   But we completely understand the concern raised and our team is actively looking into ways for admins to self serve the information of which issues are over the limit/approaching the limit to address this.

[Shiraine Liu]

Hi @Antoine _Klee Group_ 

Unfortunately, at the moment, we don't have a way for you to find out which issues are about to hit the limits. Our team is actively looking into ways for admins to self serve the information of which issues are over the limit/approaching the limit. 

[Konstantinos Karamitros]

@Shiraine Liu Final clarification: For the issues that have >5000 we can still GET the worklogs, as we did. Nothing changes there. If for example an issue has 7000 worklgos, we will still be able to GET all 7000. We will not get some error for the last 2000 or something, right? The only problem is if we try to ADD any additional, correct?
FYI, for people that have similar issues with limits e.g. for worklogs, we have created a process that gets some issues (all would take ages) based on e.g. a jql query, something like "timespent > 5w And Status not in (Closed, Done)". For the issues that query returns we calculate the # of worklogs. If any has >4000 we get a  notification e.g. an e-mail.

[Shiraine Liu]

@Konstantinos Karamitros Yes, you will still be able to GET the worklogs as before. Only the adding of new entities would result in an error if it exceeds the limits. The 'More Details' section of the changelog CHANGE-1133 has additional details on the specific APIs impacted. 

[André Zunido]

Do we know if this change affects the number of worklogs made using Tempo Timesheets?

[Shiraine Liu]

@André Zunido This per issue limit would be for all worklogs in Jira Cloud, including the ones created using marketplace apps like Tempo timesheets. 

[Cameron Barker]

What is the new approved method from Atlassian to automatically move time entries to a new issue when nearing the 5000 worklog limit and not be forced to manually traffic/move to new issues. (meeting, meeting1, meeting2, etc)

As many orgs, we use general worklogs for easy tracking/billing across our small company, many of our general issues IDs have hit over 5000 worklogs and we are seeing no method to view when we get close to this limit, is Jira coming up with a new method that has yet to be announced for tracking general time entries?

Edit: This is also the first email notification we received about this, and now we have to scramble to find a way around this.

Edit2: Atlassian has reported that this isn't their problem and I need to contact Tempo support instead.

[Daniel Menard]

Similarly to Cameron Barker, we use JIRA for general time tracking using Tempo and we have some general categories that far exceed the 5000 worklog limit. Having to move to a new issue everytime we hit this limit will be a massive training headache for everyone using our time tracking system. This is the first email we got about this and I hope Atlassian can backtrack on this particular point.

Edit: With major paid apps like Tempo in production, I don't see how you can proceed with this change and give admins 2 weeks notice to resolve problems. We have multiple business processes that depend on Tempo for time tracking and this is an impossible deadline for such a change with no migration path that makes any sense.

[Roman Fominych]

Hello @Shiraine Liu !

I see you have updated ChangeLog but there are still some inconsistencies. 

In old ChangeLog version it was stated that "IF worklog number > 5000 THEN worklog update is blocked". This had meant that issues that normally/naturally reach 5000 limit still support worklog updates, while those issues "over the limit" don't support worklog updates.

In the current ChangeLog version the condition regarding " > 5000 worklogs blocks worklog updates" was removed - but "PUT worklog" request is still listed as it would block updates when limit is reached. This is not consistent, could you please clarify/fix this

In the comment above you state that: "Updates of existing worklogs will still be possible when the issue has reached the limit.". "Issue hits the limit" depicts situation "number of worklogs <= 5000". But what if number of worklogs is "over the limit" when "number of worklogs > 5000" - would worklog updates still be available in this situation?

Here is the screenshot:

[Adam Hudelson]

We use Tempo for time-tracking and have gone so far as to add Jira issue IDs to recurring meetings in Outlook so that we can link our calendars in Tempo and automatically record meeting times to the correct "Internal" static Jira issue.   The Jira issues we use for time-tracking are also integrated into our accounting software and used for monthly/annual PnL reports and tax financials.  Finding a "workaround" of this new limitation is not good enough for us.  We need a real solution and soon.

[Daniel Menard]

Exactly the same situation for us with Tempo and Calendar tracking @Adam Hudelson . I have booked in a call with @Shiraine Liu to discuss the issue and have escalated the issue to Tempo support. I suggest you do the same.

A quick calculation shows that for a daily meeting attended by 30 people, you would hit the worklog cap within only a couple of months and have to change over to a new issue key. For larger teams this could be an even bigger headache.

Considering the amount we pay for JIRA and how integrated it is into the operations of our business, this is quite an arbitrary limitation. While it may be fine for 99.999% of issues, the remaining part is business-critical and frankly a core part of Atlassian's offering given that it now encourages the use JIRA for work management.

[Susan Hauth _Jira Queen_]

Hi,

We are facing the same problem as Daniel and Cameron.  WE have been using Tempo Internal Issues for 10 year, so thus have 10 years worth of worklogs that exceed the 5000 limit.   I would be happy to maybe purge old worklogs from 5 years ago, but how would I do that??

Also a little stressed as it seems I have 2 weeks to figure out what to do.  Otherwise I will have half the company freaked out because they can't add their meeting time to the Jira internal issue that we use via Tempo.

Shiraine, how do I arrange a call on this? 

Susan

[Paul York]

We have exactly the same issue with this as many other Tempo users and to say we have two weeks to find a work-around is crazy...

Has anyone had any formal response from Tempo and how they intend to work with this?

[Shiraine Liu]

Hi all,

We understand that the use case of using a single Jira issue to track worklogs indefinitely is a convenient practice, but is not a best practice and optimal usage pattern. Continually adding worklogs to a single issue may lead to performance and reliability problems as the size of data grows. 

A suggested workaround for this scenario would be to set up an automated workflow to create a new issue periodically (eg: every quarter) for adding worklogs. The previous and next quarters' issues can be linked for easy reference and would help maintain a manageable size for each issue to ensure the stability of the platform.

I will update the community post to include this suggested workaround.

@Cameron Barker @Daniel Menard @Adam Hudelson I look forward to discussing more in our call tomorrow. 

@Susan Hauth _Jira Queen_ @Paul York Feel free to book some time on my calendar to discuss more around limits for your specific Jira instance.

[Paul York]

The problem with the suggested workaround is that it isn't really a great option for organisations with recurring meetings already issued and coded to a specific JIRA. Is Atlassian suggesting that we re-issue all of these meeting requests now and then once a quarter going forward? 

If so, it's not a great thing to spring on your customers with two weeks notice.  If we had 6 - 12 months to prepare and plan for the impact of this, adapting our working practices over this time may have helped soften the blow, but this seems really harsh.

I've logged a support ticket with Tempo, as I presume they were aware of this upcoming change and will hopefully have other workable suggestions.

From a developer perspective, I can't help but wonder why implementing pagination on the API for these entities wasn't a viable option. It could have allowed datasets such as the work log (which I would expect to be the main one that would have benefitted from a higher limit) to have carried on supporting apps like Tempo where they are fundamental.

[Susan Hauth _Jira Queen_]

Hi,

We have 300+ users who have marked INTERNAL-1 - Vacation as their favorite.   And I have to rotate this issue through every Quarter?  They have to what, search for it when it gets closed off? 

This is not a viable solution.

Susan