Tempo’s Solutions for Atlassian’s 10K Worklog Limit

[#1]

We’re excited to share important updates that will help you navigate Atlassian’s upcoming 10K worklog limit while using Tempo Timesheets.

As Atlassian moves to improve performance and reliability of Jira Cloud, a cap on the number of worklogs per issue was introduced. This limit was initially set at 5,000 and has now been increased to 10,000. Atlassian has released Bulk Worklog Move and Delete APIs to help customers adapt to this new limit. However, if you are using Tempo Timesheets, Atlassian's Bulk APIs may not work as specific Tempo solutions are needed, particularly when dealing with:

• Keeping Tempo and Jira worklogs consistent – If you’re using Tempo Timesheets to log your time and then use Jira’s Bulk Worklog APIs to delete or move Jira worklogs, it may result in discrepancies between worklogs in Tempo and Jira.
• Moving worklogs from closed periods and approved timesheets - Tempo Timesheets has historically not provided the ability to do so within the UI or Tempo API, until now.

Tempo has developed solutions that will allow you to bulk move and delete worklogs ahead of the limit rollout. We’re also introducing an alternative syncing method for Internal Issues that may allow your organization to reduce the change management associated with the 10K limit.

Preparing for the limit rollout

Find out which issues are near or at the limit

To help you prepare, it starts with determining which Jira issues are near or at the 10K limit.

• For Cloud users with API querying capability: Use Atlassian’s Get Issue Limit Report API to identify issues approaching the limit.
• For those without API querying capability: Use the Worklog Count column in Tempo Reports. Simply run a Logged Time Report, include the Worklog Count column, and sort it in descending order to spot potential “problem issues.”

Once identified, you can decide whether to proactively move or delete worklogs before the limit is enforced, or create new issues as needed after it is enforced.

Bulk move and delete worklogs from closed periods and approved timesheets in Timesheets

Released to all customers [documentation]

For those who choose to move or delete worklogs to keep using existing issues, we’ve introduced a new Override Mode that will allow Tempo Admins to bulk move or delete worklogs from closed periods and approved timesheets, either via the UI or Tempo Public API. These actions will help ensure your key issues remain well below the 10K limit.

Limitations:

• Bulk actions are currently limited to 5,000 worklogs in the Bulk Worklog Editor.
• Tempo Bulk APIs are not yet available, but users with scripting capabilities can use our existing worklog APIs to mimic bulk move and delete actions.

Options once the limit is enforced

Create new Jira issues

Regularly monitor your issues using Atlassian’s Get Issue Limit Report API or the Worklog Count column in Tempo Reports. If an issue reaches the limit, you’ll need to create a new Jira issue, as Timesheets will no longer allow time to be logged against it.

Periodically move or clean up worklogs

If you prefer to keep the same Jira issues active, use Tempo’s bulk move and delete features to periodically archive or clean up worklogs.

Enable daily summary worklogs to extend Tempo Internal Issues’ usability to 10,000 days

Status: Released to all customers [documentation]

By default, creating a Tempo worklog automatically generates a corresponding Jira worklog. However, many of you have raised concerns about quickly reaching the new worklog limit especially when using Tempo's Internal Issues. We want to help our customers avoid the potential confusion and change management challenges that could result from frequently having to create new Jira issues.

To help you manage the worklog limit, we’re introducing an alternative method that aggregates worklogs in Internal Issues into a single Jira worklog per issue per day. This option significantly reduces the number of worklogs created, effectively extending the usability of an Internal Issue to 10,000 days before reaching Atlassian's limit.

Please note, however, that this method is not ideal for all organizations. We do not recommend this approach for organizations that:

• Use Plans (formerly Advanced Roadmaps), Capacity Planner, and/or other third-party apps to track the Original Estimate, Remaining Estimate, Time Spent, and other worklog-influenced fields related to Internal Issues in real-time
• Need minute-by-minute worklog reporting on said fields while using Jira’s API, reports, and/or gadgets for any worklog-related reporting
  
  

Try the solutions in Timesheets

Both solutions have now been released to all customers, so you can directly try them out in Timesheets. We look forward to your questions and feedback, and hope that these solutions help you navigate Atlassian’s 10K worklog limit. 

[Stefan Krooshof]

Hi @Kathryn Vargas _Tempo_ ,

You mentioned that "users with scripting capabilities can use our existing worklog APIs to mimic bulk move and delete actions."

I've managed to achieve the Bulk Delete action by searching for issues by date and iterating through them using the Delete Worklog REST API.

However, for Bulk Move, are you suggesting a workaround that involves deleting the existing worklogs and then recreating them under the new Jira issue using the Create Worklog API? Or is there an actual method that allows updating the associated Jira issue for existing worklogs directly?

Looking forward to your insights!

Best regards,
Stefan

Edit: the existing for below parameter in the Create worklog REST API (and not anywhere else) confirms the solution would be re-creating worklogs: 

bypassPeriodClosuresAndApprovals

boolean Bypass period closures and approvals. If the value is 'true' and the period is closed, the worklog will be created. You need the Tempo Administrator permission and Override Mode enabled. [TempoLab only]

And that the period would need to be Opened, or Override Mode is enable (which requires TempoLab registration). 

[Kathryn Vargas]

Hi @Stefan Krooshof, thanks for trying out the features and my apologies for the delay in getting back to you :( 

You're right - the solution is indeed to recreate the worklogs. In the meantime, we have released Override Mode which hopefully should help. In case you have any other questions or feedback, let us know! 

Best, 
Kathryn 

[Garth Hume]

Hi, the bulk edit option works well.  However, I am running into an issue for people the that have left our organization.  It is unable to move those logs.  How do you recommend dealing with these?

[Michaela Kubicová]

Hi, 

I've got a question regarding the bulk move option. I've tried to move the work logs, however I am receiving the following error. 

The account in TEMPO to which I am trying to move the work-logs is not archived or closed. 

Is there anything I am doing wrong?

Thanks

[Shawn Stevens]

I'm late to party here about the Worklog limit and didn't think my company would be close to the limit but we had a couple that were. 

Based on options from the TEMPO documentation. 

1. Create a new JIRA card, that will replace the old card (INT-2 would no longer be used and INT-6 would)

    make it an internal card and then set to daily aggregration

2. Delete or move worklogs

I would have preferred to keep the original INT-2, but it felt like the quickest fix was to just create the INT-6 replacement and then communicate to the organization about the change. 

Am I missing anything here. 

[Paul York]

:( This has just bitten us - after clearing/moving worklogs a few months back, all our employees can no longer log internal work as we've exceeded the 10k limit far quicker than expected. 

We're trying to bulk move worklogs to get us back up and running as quickly as possible using the bulk editor, but it seems to be hanging after 10 minutes, and the progress bar shows 0%.

Whilst Tempo thinks it's "running," we can't move any other worklogs via the UI, so our company's time recording solution is effectively down.

This is a terrible experience.

[Karin Kennergren]

Firstly, it was communicated as a happy feature development within a newsletter - it should have been targeted and acknowledge as a challenge that needed prevention. 

Secondly, the migration  now freezed as for the other users and I need to do a quick fix after trying since 10. Did you stresstest this migration? 

Thridly, no answers from Customer Support, gthankfully my Account Manager is assisting me so kudos to him. 

And lastly - will you be providing a full Best Practise since it is a solution that needs constant "fixing"? 

[Karin Kennergren]

Are you even monitoring this feed? 

[Paul York]

Is anyone else having problems with this solution?  We've logged a support ticket, but the bulk log editor doesn't seem to work today and is just hanging even when we try bulk editing one record.

[Michael Pohl]

@Kathryn Vargas _Tempo_we are also unable to bulk move issues. Since initiating a move of a few hundred issues Friday afternoon, the bulk edit tool reports only a "Changes are being applied" message, with no progress. Is this a known problem?

[Linda Redgate]

10-December-24 Update - Everything seems to be working now

09-December-24

I have been attempting to move worklogs all day today with ZERO success.  The Override functionality is On and Ihvae been able to use the Bulk Edit/Move functionality in the past so I have the correct permissions.

I have tried with only a handful of worklogs as well as many and nothing works

What can I do to resolve ASAP as I have hundreds of people who have been unable to log time since this rule was implemented

This is the screen which never changes!

[Muhammad Majeed]

Same issue here. Since this morning, we've been bounced back and forth between support teams with no clear resolution. It seems like these recent changes are causing more confusion than improvements, especially for teams dealing with high worklog volumes. A better explanation or workaround would be appreciated.

[Joseph HANI]

We are experiencing the same issue as others: the bulk editor is stuck, and after waiting for 30+ minutes, nothing happens.

We’ve made the necessary changes using the Jira API to bulk move worklogs, which works on Jira’s side, but Tempo still shows that the limit has been reached. Could you clarify what this means? Do we need to take action on both Jira and Tempo to resolve this?

Additionally, some of the users who logged time are deactivated in our instance. Can you confirm if your bulk edit functionality work for such cases?

It also seems that Atlassian deployed the limits last Friday (an interesting choice for a rollout day 😡), even though the change was announced for December 2nd….

[Mark Hawkins]

@Kathryn Vargas _Tempo_  as per the other commentors, I am experiencing the same issue, where after trying to bulk move worklogs to a second ticket, the screen UI is stuck on "Changes are being applied" and no progress...

If any Tempo support person reads this, my support ticket is:  TCS-77319

[Iona Augustine]

I found that what API gave me as the number of worklogs per issue is different to the one on the UI. Is there a delay of this number to reflect on the UI after worklogs being moved via API?

Users are unable to log time with error: 

Error!

Can't add a new worklog because Jira's worklogs per issue limit has been exceeded

even though in API the worklog is 5

Anyone has this problem?

[Joseph HANI]

It seems that the bulk editor is working again ! 

[Muhammad Majeed]

On our side, it's working again too. Good luck and have fun moving everything.

[Paul York]

UPDATE: It looks like this may be expected behaviour and occurs when our bulk edits get queued behind other requested work.  After around 15 minutes, the responses from Tempo now include data, and the progress bar has started moving :) 

I suspect the "failure" yesterday was just due to many people trying to move worklogs and the system being under massive strain.  

Fingers crossed, this is the last time I need to do this for a while!

---

Hmmm, I've had enough success this morning to get our company working again, but the bulk editor now appears to be doing nothing again.

When I look in the browser dev tools, I can now see no JSON data is being returned by the service; however, 10 minutes ago, it was returning a package of data, including how many records were included in the update and a count of how many had been processed and how many had errors etc.  

It would be good to understand if it's down for everyone again or if it's only a partial outage caused by throttling, load etc..

.

This feels like it could be a routine "fun" activity if we have to spin the roulette wheel frequently and hope it's working to keep the lights on

[Joseph HANI]

Just a quick information: for deactivated users in your instance, you might encounter this error message:

“User does not have permissions to log work on the destination project.”

These users are no longer in the company, and we cannot reactivate them. However, we still need to retain the history of their worklogs, which creates another problem because in the bulk editor, it’s not possible to filter them out, which means we’ve now hit the 5,000 worklog limit and can’t move any more logs …

I’ve opened a support request regarding this and will share their response

[Paul York]

We've hit that limitation too, but as a small company, it doesn't affect us too much.

It would be good to hear what the feedback is and understand how larger firms are expected to work around that. It seems like it could be a problem for any organisation with a reasonable number of users...

[Muhammad Majeed]

On the one hand, I appreciate that the community is at least engaging here, sharing solutions, and keeping each other up to date. On the other hand, it’s alarming that the Atlassian staff isn’t stepping in to address the issue.

We are trying to move over 50k worklogs. Of course, the next error messages are now popping up.

[Karin Kennergren]

I have notified my account manager about missing information - and monitoring of this comment feed. 

My next step as soon as my tests assure me that the migration tool is up and running and how to handle deactivated users is to create current year as temporary, given that they will hold for 10K That at least will give me and my internal customers control of this year at least. 

Currently made copies of internal issues with name standard start Temporary just to keep afloat and they use it for all internal tasks just so we can have some control of what is where. 

[Muhammad Majeed]

It seems that all former users and deactivated users cannot be moved. What is the plan to resolve this issue?

[Muhammad Majeed]

FYI:

To help our customers manage and adapt to this limitation, Tempo provides several tools:

• QWorklog Count Column:
  In the Tempo Logged Time Report, you can enable a Worklog Count column to identify issues nearing or exceeding the limit. For more information, please see: Adding and Removing Columns and Work Attributes 
  ⚠️Note, the data shown depends on the timeframe selected, so you need to set the report from the date the issue was created.
• Override Mode:
  This mode enables you to bulk move/delete worklogs, even from closed periods or approved timesheets, allowing a more streamlined process. For details, see: Modifying Worklogs in Closed Periods or Approved Timesheets
• ⚠️ Please note, worklogs for inactive or deleted users  cannot be moved.
• Aggregating Internal Issues Worklogs:
  A new feature helps aggregate worklogs for internal issues to mitigate the impact of the restriction. Learn more here: Aggregating Internal Issues' Worklogs When Syncing with Jira 

[Shawn Stevens]

Is the "Aggregating Internal Issues' Worklogs When Syncing with Jira "  feature enabled or is that still only on TempoLab. I was hoping to see a way to validate that it was working as I have have created new Internal Tickets for the ones that hit the 10K limit but turned on the aggregate worklogs when syncing to JIRA. 

I'm just not 100% sure how to validate it is actually doing what I expect. I created a new internal ticket INT-6, it is showing 360 entries in Worklog counter in tempo and I see all the users that have logged time.