Jira Cloud regression: worklogDate JQL returns incorrect results

Jira Development Jira Cloud
1

I’m bringing this issue to the Atlassian Developer Community in hope that it gets visibility within Atlassian and reaches the team that can investigate and address it.

On September 9, we received two independent support requests from our customers reporting the same problem with our Marketplace app.

After investigating, we found that the underlying problem appears to be in Jira itself, specifically in JQL queries involving worklogDate.

Queries such as:

worklogDate >= YYYY-MM-DD AND worklogDate < YYYY-MM-DD

do not reliably return issues that have worklogs within the specified period.

Editing an existing worklog within that period causes the affected issue to immediately start appearing in the JQL results. This strongly suggests an issue with Jira’s indexing of worklogs rather than with our application.

We were able to reproduce the behavior independently on our own Jira Cloud instance.

Because of that, I reported it to Atlassian Support as a “Technical issues and bugs” for our Jira instance, explicitly explaining that:

  • the problem is reproducible directly in Jira;
  • it affects multiple customer Jira instances;
  • it can be reproduced without relying on our application’s business logic;
  • we provided reproduction steps and screenshots from our own Jira instance demonstrating the incorrect JQL results.

Despite this, Jira Support redirected us to Developer and Marketplace Support. I tried to clarify that the evidence points to a Jira platform issue rather than an issue in our Marketplace app, but was advised that Developer Support should investigate it.

Following their recommendation, I opened a corresponding Developer and Marketplace Support ticket as well.

Now it’s more than 24 hours since the initial report. So far, we have no indication that the underlying Jira issue has been identified or that a fix is being prepared, while the problematic behavior remains present in production.

This puts us, as a Marketplace vendor, in a difficult position: our application no longer works as intended because it relies on JQL results returned by Jira, while there is very little we can do on our side to correct those results.

Meanwhile, our customers experience this as a problem with our product, which creates both support burden and a real risk of losing customers.

We are also concerned that this may be related to a progressive Jira Cloud rollout. We currently do not have enough information to confirm that, but the timing and reports from multiple instances make it a possibility worth investigating.

I’m posting this publicly not to assign blame, but because the normal support path has so far left us between Jira Support and Developer Support while a production issue continues to affect our customers.

If anyone from Atlassian can help get this in front of the appropriate Jira/JQL/indexing engineering team, it would be greatly appreciated.

I would also be interested to hear from other Marketplace vendors or Jira Cloud users: have you recently observed incorrect results from worklogDate JQL queries, particularly results that become correct after editing a worklog?

2

Update

As Atlassian previously announced in CHANGE-3235, Jira Cloud now indexes only the 1,000 most recent worklogs per issue, while a single issue can contain up to 10,000 worklogs.

In my view, this creates a significant inconsistency. JQL clauses such as worklogAuthor, worklogDate, and worklogComment can no longer be expected to return complete results for issues with more than 1,000 worklogs.

If anyone at Atlassian responsible for this area is following this discussion, I would strongly suggest considering one of the following approaches:

  • index all 10,000 supported worklogs/comments, as was effectively possible before;

  • align the maximum number of worklogs with the indexing limit; or

  • reconsider support for JQL clauses that cannot reliably search all data they are expected to cover. Having Jira accept up to 10,000 worklogs while JQL can search only the most recent 1,000 makes these clauses inherently incomplete and potentially misleading for users and apps relying on JQL results.

Separately, our current issue does not appear to be explained by the 1,000-worklog indexing limit.

On our Jira instance, the worklogDate JQL clause fails for an issue with fewer than 1,000 worklogs. The same query worked correctly only a few days ago.

This suggests that there may be a separate recent regression or an issue with Jira’s worklog indexes. Atlassian is currently investigating our case, and I will post an update when we have more information.

3

We’ve observed something very similar on our side and also reached out to Atlassian about it.

In our case, we had customers where worklogDate and worklogAuthor JQL queries suddenly stopped returning issues even though the relevant worklogs were still available through the REST API.

What was particularly interesting is that this also happened for an issue with well below 1,000 worklogs, so it could not be explained by the newly introduced 1,000-worklog indexing limit.

A few days later, without any changes on our side or on the customers’ side, the same JQL queries started working again.

Atlassian told us that the 1,000-worklog limit started rolling out in August 2026 and suggested that the temporary behaviour we observed could have been a transitional artifact during the rollout. They also confirmed that only the most recent 1,000 worklogs per issue are now searchable via worklog-related JQL clauses.

We also tested this on our own instance. We have an issue with more than 2,500 worklogs. Before the rollout, we were still able to find the issue via JQL using some of its oldest worklogs. After the rollout stabilised, this is no longer the case and the behaviour now matches the documented 1,000-worklog limit.

So it looks like there may have been two things happening at the same time: the new 1,000-worklog limit itself, and some temporary indexing inconsistencies while it was being rolled out.

4

you’re not mentioning how inaccurate the retrieved results are. there is a possibility of a timezone mismatch. I am not sure if this changed, but I think the worklogs were saved by default in australia’s timezone, which in most cases is +/- 1 day from eu/us - which may cause incorrect results if queried just by date in your timezone

5

Worklogs are saved using Jira’s timezone context, so timezone differences can affect how a worklog date is interpreted around midnight. In practice, though, that would normally result in at most a one-day difference.

In our case, the affected queries covered multi-day ranges and the issue was not returned at all, so a timezone shift would not explain the behaviour we observed.

I also confirmed the new 1,000-worklog limit on our own Jira instance. For an issue with more than 2,500 worklogs, JQL now only appears to consider the most recent 1,000. Older worklogs beyond that window effectively behave as if they did not exist from the JQL search perspective.

6

Companies are raising these issues and it has nothing to do with 1000 worklogs indexing limit.
When the JQL contains static dates (from - to) EVEN for very recent worklogs, the work items are not returned in the Search Work Items menu and obviously through the API. Even for work items less than 1000 worklogs.

I am not sure that Atlassian is aware about the situation.

7

Hi ,

We have the exact same two problems with our clients. Is Atlassian fixing the issue about the indexing inconsistencies ? Did they answer with a Timeline for this ?

Our clients are facing the problem of non answer even with work items having well below 1000 worklogs for queries containing worklogDate and worklogAuthor

8

Hi community,

As mentioned in the initial post, I opened a support ticket for this issue on September 9. After a bit of a journey through the support channels, the issue was escalated for investigation yesterday.

Today, I received an update that Atlassian has identified the problem and is working on a fix.

The current ETA is today - fingers crossed :-).

9

but whats the fix? making 1000 worklogs searchable on every issue?

This is the response I got week ago:

Root Cause

The behaviour you observed — where worklogDate and worklogAuthor JQL queries failed to return issues despite worklogs being present via the REST API — is related to newly enforced JQL search limits for worklogs in Jira Cloud, which began rolling out in August 2026.

As per our public changelog:
:backhand_index_pointing_right: Atlassian developer changelog

Jira Cloud now enforces a limit of 1,000 searchable worklogs per issue for JQL. Only the most recent 1,000 worklogs per issue are indexed and searchable via worklogDate and worklogAuthor. Worklogs beyond this window are not returned by JQL but remain fully accessible via the issue view and the REST API.

Regarding the “first 100” pattern you observed

The documented limit is 1,000 (most recent), not 100. The behaviour where only worklogs among the first ~100 created were visible to JQL was likely a transitional artifact during the enforcement rollout and is not the expected steady-state behaviour. Since the issue self-resolved on September 3 for both customer sites, this is consistent with the rollout stabilising for those tenants. If the issue recurs, please let us know immediately with fresh trace IDs so we can investigate further.

Important clarifications

  • :cross_mark: This is not data deletion — all worklog data remains intact and accessible via the UI and the REST API (GET /rest/api/3/issue/{issueIdOrKey}/worklog).

  • :white_check_mark: The REST API has no such search limit — it always returns all worklogs regardless of count.

To answer your specific question:

Should JQL still be able to return an issue based on very old worklogs, even when the issue has well over 1,000 worklogs?

It depends on recency. JQL indexes the most recent 1,000 worklogs per issue. If an issue has 2,700 total worklogs, only the 1,000 most recent are JQL-searchable. If the worklogs you are querying fall within that window, they will be returned. Older worklogs will not appear in JQL results but remain accessible in full via the REST API.

Recommended approach for your app

Since worklogDate / worklogAuthor JQL is bounded by the most recent 1,000 worklogs, we recommend:

  1. Use JQL to discover recently active issues — reliable within the 1,000-worklog window.

  2. For complete worklog history, use the REST API directly: GET /rest/api/3/issue/{issueIdOrKey}/worklog (paginated) — no search limit applies here.

Please let us know if you have any further questions or if the issue reoccurs. We appreciate your partnership and the detailed analysis you provided throughout — it was instrumental in getting to the bottom of this.

And when asked on Monday about the timeline for when the rollout of worklog indexing is expected to be completed, I got:

Worklog indexing should be completed by now.

:thinking:

10

I really wonder whose idea was it to allow 5000 worklogs on issues and only let latest 1000 to be searchable, brilliant.

11

they even increased the limit to 10,000 some time ago

12

Up to 10K worklogs per issue and only the latest 1K are supposed to be searchable - and currently even those may not be ;-). An interesting design, with an even more interesting implementation.

13

Update: Atlassian has just informed us that they have fixed the indexing issue affecting the latest 1,000 worklogs per issue.

I checked our production Jira instance, where I originally reported the problem, and can confirm that the issue is now resolved there. However, I can still reproduce the same problem on our test Jira instance. I’ve asked Atlassian whether the fix was applied specifically to our instance or is still being rolled out across Jira Cloud.

For those who experienced the same issue, could you please check your Jira instances and let us know here whether the indexing problem has been resolved for you?

14

I have still customers facing the issue today. The latest one at 15:30 CET TIME. As you have a support ticket already , could you ask them if they applied a general fix ?

15

Really not a good solution. In the JQL there is a worklogdate , so if the issue has more than 1’000, and none of the last 1’000 falls in the range, than we will not have the work item in the answer.
So the 1001 th worklog, that falls in te range will not appear at all, as we don’t get the work item in the first call. :frowning:

16

The worst part is that Atlassian provides no alternative, like a REST API endpoint for retrieving all worklogs within a given date range. If they introduced this indexing limit, they should at least provide us with such api endpoint. Currently, there is no technical possibility to do this without synchronizing and storing all worklogs in your own database, which would be a hell when moving to Forge.

17

I confirm that i have one client experiencing the issue today. So it seems that it was fixed only for your prod instance and not a general fix.

18

I can also reproduce the same issue on my dev Jira, so I assume the problem is quite widespread and they may be fixing it per instance/request.

I suggest you or your affected customers open Jira Support tickets as well. The situation is really annoying - after the recent rollout, JQL search for worklogs (even within the latest 1K) simply doesn’t work correctly, more then a week passed and is no global fix.

19

Update I got from the Atlassian today:

We identified a regression in our internal indexing service where only the first 100 items from list-type fields (such as worklogs) were being sent to the search index. This caused JQL worklog searches to return incomplete results for issues with more than 100 worklogs.

Current status: The issue has been mitigated; worklog-based search clauses have been temporarily disabled/moved to shadow mode while a permanent fix is being developed. The fix will be deployed in the next scheduled release cycle.

20

Yes, I got the same update. Fingers crossed.